Bug #63618 [Dup]: 5.3.19-1~dotdeb.0 32bit arch

Edit report at https://bugs.php.net/bug.php?id=63618&edit=1 ID: 63618 User updated by: roman dot hlynovskiy at gmail dot com Reported by: roman dot hlynovskiy at gmail dot com Summary: 5.3.19-1~dotdeb.0 32bit arch Status: Duplicate Type: Bug Package: Filesystem function related Operating System: linux PHP Version: 5.3.19 Block user comment: N Private report: N New Comment: Yep, I have a constructive proposal. I have 10y+ experience working for 1000+ company, so according to my experience a project created to solve a particular problem will either become never-ending story or will be realized by the time no one needs it. I agree - there are thousands of module ecosystem around php, but all those testing efforts should be made by the module-developers and their user ecosystem, not the core php team. I am not quite familiar with php development approach, but for example linux way looks rather effective. stable stuff goes to even-numbered releases, test stuff goes to odd-numbered releases. I am pretty sure this is not the only bug waiting for 'big project to bang' and fix it. So my proposal would be to collect all those bugs, fix all of them in one shot and provide non-stable -bugshot release for those who will be willing to test it within their app ecosystem. Also try to understand the situation from user-perspective. If there is a bug, which has several pages of workarounds published on the official page and most probably it has been in place for ages, it looks like something is wrong with bug-fix approach in php. If this is so - how can I trust a product, which might have a critical bug affecting overall system performance (for example) for my product and which could have never been fixed. I would never feel comfortable in this situation. Previous Comments: ------------------------------------------------------------------------ [2012-11-27 10:59:53] johannes@php.net PHP's internal integer type is a signed long. with 32bit 2336962885 is out of range. While properly printing it gives you the correct value: php -r 'printf("%u", -1958004411);' 2336962885 Besides that there are projects for large file support (while that's not as relevant on most 64bit systems [except windows 64bit] these days where it works out of the box) and for aritrary size "integer" types. But both projects aren't trivial due to the wayand amount of 3rd party libraries PHP interacts with. If you have a constructive proposal/solution for those we're more than happy to implement those, though. ------------------------------------------------------------------------ [2012-11-27 07:11:39] roman dot hlynovskiy at gmail dot com hmm, feature is something missing in a product, however this one is a plain bug. perl, python, 3-line c program, stat, ls they all return correct size. what is wrong with php to return correct filesize? this is strace cut: --- stat64("/home/data/bigfile.data", {st_mode=S_IFREG|0644, st_size=2336962885, ...}) = 0 write(1, "-1958004411\n", 12-1958004411 --- it's clear that from system level correct size is returned. it's a matter of using correct types to store and return the value from php perspective ------------------------------------------------------------------------ [2012-11-27 06:40:45] pajoye@php.net LFS is not supported by default. See other feature requests about this issue. ------------------------------------------------------------------------ [2012-11-27 06:16:05] roman dot hlynovskiy at gmail dot com Description: ------------ filesize returns negative values for big files Test script: --------------- $f = '/home/bigfile.data'; $s = filesize($f); print "$s\n"; Expected result: ---------------- 2336962885 Actual result: -------------- -1958004411 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=63618&edit=1