|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74395 Support 4g files in stream_copy_to_stream() on 32 bit php builds
Submitted: 2017-04-09 09:34 UTC Modified: 2021-07-06 14:18 UTC
Avg. Score:4.3 ± 0.9
Reproduced:6 of 6 (100.0%)
Same Version:5 (83.3%)
Same OS:3 (50.0%)
From: maggus dot staab at googlemail dot com Assigned: cmb (profile)
Status: Wont fix Package: Streams related
PHP Version: 7.1.3 OS:
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: maggus dot staab at googlemail dot com
New email:
PHP Version: OS:


 [2017-04-09 09:34 UTC] maggus dot staab at googlemail dot com
stream_copy_to_stream() expects the 3rd arg to be a integer which limits its max value on 32 bit builds. This means some real world use cases dont work because the MAX_INT is not big enough to handle 4GB+ filesizes.

Could we handle the arg like a string to support "huge files" on 32 bit php?

Expected result:
Copy of streams with filesize >= 4gb should be supported 

Actual result:
stream_copy_to_stream() expects parameter 3 to be integer, string


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-04-09 09:47 UTC] maggus dot staab at googlemail dot com
As userland workaround exists for this exists I guess a builtin handling of such files would/should also work?


Got it working with following patch:

while (!feof($body)) {
// stream_copy_to_stream($body, $output, $contentLength);

Instead of copying entire file at once, it copies chunks of 8MB
Bit crude, but the concept works :)

Based on:


 [2017-04-09 09:52 UTC] spam2 at rhsoft dot net
the better question is why is PHP on 32bit limited that way?
couldn't it use longint as other applications do?
 [2017-04-10 12:41 UTC] maggus dot staab at googlemail dot com
in 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."
 [2017-04-14 12:58 UTC]
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.

 [2017-04-14 13:02 UTC] 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 13:05 UTC] 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 19:38 UTC]
@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. 

 [2020-09-01 12:27 UTC]
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.
 [2021-07-06 14:18 UTC]
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-07-06 14:18 UTC]
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] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Apr 15 23:01:29 2024 UTC