Bug #74395 [Opn]: 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 Type: Bug Package: Streams related PHP Version: 7.1.3 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2017-04-10 12:41:19] maggus dot staab at googlemail dot com in https://github.com/nextcloud/server/issues/1707#issuecomment-292937033 it was pointed out why 32 bit builds are used in the first place: "Most SBCs such as Raspberry Pi and Odroid devices still rely on 32 Bit. Therefore this change is a real big thing for those." ------------------------------------------------------------------------ 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