Bug #74395 [Opn->Wfx]: Support 4g files in stream_copy_to_stream() on 32 bit php builds

Edit report at https://bugs.php.net/bug.php?id=74395&edit=1 ID: 74395 Updated by: cmb@php.net Reported by: maggus dot staab at googlemail dot com Summary: Support 4g files in stream_copy_to_stream() on 32 bit php builds -Status: Open +Status: Wont fix Type: Bug Package: Streams related PHP Version: 7.1.3 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: The other ticket has been changed to doc issue, and given the drawbacks, technical difficulties and limitations to implement this, I'm closing this ticket as WONTFIX. If anybody is still interested in beeing able to copy large streams on 32bit architectures (or more generally 64bit integers, or full LFS), please pursue the RFC process[1]. [1] <https://wiki.php.net/rfc/howto> Previous Comments: ------------------------------------------------------------------------ [2020-09-01 12:27:22] cmb@php.net Well, this should probably wait on the outcome of bug #54902 anyway, because the other ticket is about inconsistencies regarding files between 2GB and 4GB. ------------------------------------------------------------------------ [2017-04-14 19:38:55] ab@php.net @spam2 well, 2017 and still someone cares about 32-bit :) But joke aside, you can simply benchmark 64-bit math on 32-bit platform, to see diff. It can also be hardly worth the efforts to do big refactorings or even tricks, where modern RPI or others ship with a 64-bit processor, and eventually 32-bit will die out same way it did already for desktops, etc. Thanks. ------------------------------------------------------------------------ [2017-04-14 13:05:41] spam2 at rhsoft dot net > 32-bit PHP is strict and the key is simplicity and performance someone needs to show me a real world usecase in 2017 where the operating system is 32 bit and performance really matters - playing around on a Raspberry is hardly performance relevant beause it can't stand concurrency load anyways ------------------------------------------------------------------------ [2017-04-14 13:02:43] spam2 at rhsoft dot net > for date it's still ok well, in 2038 it's too late, you likely have to deal with timestamps pointing in the future years before... ------------------------------------------------------------------------ [2017-04-14 12:58:45] ab@php.net 32-bit PHP is strict and the key is simplicity and performance. To have 64-bit integers always is much bigger topic than just changing the datatype. That would mean a significant performance impact, and aslo things like date, file stat, PHP streams, external libs and many portability cases would require a deep refactoring in PHP. For stat - well, that's an issue, for date it's still ok. The suggested string conversions in the case look not justified. LFS is not something required every day, so performance is more relevant. In some cases it is solvable with a completely sane approach like listed in the first comment, some workarounds for stat are also possible, even not nice. I would tend to set this to won't fix therefore, as it sohuld be either some proper core solution, or 64-bit is fully suitable for the goals otherwise. Thanks. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74395 -- Edit this bug report at https://bugs.php.net/bug.php?id=74395&edit=1