Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Drop support for 32bit builds »

[RFC] Drop support for 32bit builds

php.internals

Marc

1 year ago
Hi, During the discussion about the year 2038 issue it turned out that maybe it's time to drop support for 32-bit of PHP completely. Based on that I have created an RFC to deprecate 32-bit build in 8.next and drop support for it in 9. RFC: https://wiki.php.net/rfc/drop_32bit_support

Calvin Buckley

1 year ago
On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> wrote:
> > Hi, > > During the discussion about the year 2038 issue it turned out that maybe it's time to drop support for 32-bit of PHP completely. > > Based on that I have created an RFC to deprecate 32-bit build in 8.next and drop support for it in 9. > > RFC: https://wiki.php.net/rfc/drop_32bit_support
I think the biggest arguments against this would be: - embedded systems; think of PHP in use for i.e. router web UIs. While I suspect a lot of these are going to be i.e. AArch64/RV64 in the future, there might be a long tail of existing systems. Of course, how many would upgrade to PHP 9? - WebAssembly; I don't know how widespread the Memory64 proposal is yet. We're using WebAssembly in the docs pages for runnable examples. And some niche cases like i.e. iSH (which emulates x86-32 on iOS). The other options include making zend_long always 64-bit and accept the performance penalty for 32-bit, or making 32-bit best-effort rather than providing any guarantees.

Ben Ramsey

1 year ago
> On Jun 19, 2025, at 11:08, Calvin Buckley <calvin@cmpct.info> wrote: > > On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> wrote: >> >> Hi, >> >> During the discussion about the year 2038 issue it turned out that maybe it's time to drop support for 32-bit of PHP completely. >> >> Based on that I have created an RFC to deprecate 32-bit build in 8.next and drop support for it in 9. >> >> RFC: https://wiki.php.net/rfc/drop_32bit_support > > I think the biggest arguments against this would be: > > - embedded systems; think of PHP in use for i.e. router web UIs. While I > suspect a lot of these are going to be i.e. AArch64/RV64 in the future, > there might be a long tail of existing systems. Of course, how many > would upgrade to PHP 9? > > - WebAssembly; I don't know how widespread the Memory64 proposal is yet. > We're using WebAssembly in the docs pages for runnable examples. > > And some niche cases like i.e. iSH (which emulates x86-32 on iOS). > > The other options include making zend_long always 64-bit and accept the > performance penalty for 32-bit, or making 32-bit best-effort rather than > providing any guarantees.
Last night, I was giving some thought to reviving Andrea’s Big Integer RFC[^1]. This is something I’ve wanted for a long time (especially for my ramsey/uuid library, among other things). Andrea had a work-in-progress PR[^2]. I’m not sure the current state of it. It’s from 2014 and was originally written for phpng. I had planned to start teasing out bits of it into a new branch based on the current master branch to see how far I could get with it. I wouldn’t mind some help with that, if anyone’s interested. :-) If we are able to finish what Andrea started, then we would not need to drop support for 32bit builds. Cheers, Ben [^1]: https://wiki.php.net/rfc/bigint [^2]: https://github.com/php/php-src/pull/876

Hans Henrik Bergan

1 year ago
On Thu, Jun 19, 2025, 18:24 Ben Ramsey <ramsey@php.net> wrote:
> > On Jun 19, 2025, at 11:08, Calvin Buckley <calvin@cmpct.info> wrote: > > > > On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> wrote: > >> > >> Hi, > >> > >> During the discussion about the year 2038 issue it turned out that > maybe it's time to drop support for 32-bit of PHP completely. > >> > >> Based on that I have created an RFC to deprecate 32-bit build in 8.next > and drop support for it in 9. > >> > >> RFC: https://wiki.php.net/rfc/drop_32bit_support > > > > I think the biggest arguments against this would be: > > > > - embedded systems; think of PHP in use for i.e. router web UIs. While I > > suspect a lot of these are going to be i.e. AArch64/RV64 in the future, > > there might be a long tail of existing systems. Of course, how many > > would upgrade to PHP 9? > > > > - WebAssembly; I don't know how widespread the Memory64 proposal is yet. > > We're using WebAssembly in the docs pages for runnable examples. > > > > And some niche cases like i.e. iSH (which emulates x86-32 on iOS). > > > > The other options include making zend_long always 64-bit and accept the > > performance penalty for 32-bit, or making 32-bit best-effort rather than > > providing any guarantees. > > > Last night, I was giving some thought to reviving Andrea’s Big Integer > RFC[^1]. This is something I’ve wanted for a long time (especially for my > ramsey/uuid library, among other things). > > Andrea had a work-in-progress PR[^2]. I’m not sure the current state of > it. It’s from 2014 and was originally written for phpng. I had planned to > start teasing out bits of it into a new branch based on the current master > branch to see how far I could get with it. I wouldn’t mind some help with > that, if anyone’s interested. :-) > > If we are able to finish what Andrea started, then we would not need to > drop support for 32bit builds. > > Cheers, > Ben > > > [^1]: https://wiki.php.net/rfc/bigint > [^2]: https://github.com/php/php-src/pull/876
Smallest ramnode.com VPS has 512MB ram. I would run 32bit PHP on a 512mb ram VPS. I'm not longer a ramnode customer, but I used to be. I for one would be sad to see 32bit PHP go.

Marc

1 year ago
On 19.06.25 18:55, Hans Henrik Bergan wrote:
> > On Thu, Jun 19, 2025, 18:24 Ben Ramsey <ramsey@php.net> wrote: > > > On Jun 19, 2025, at 11:08, Calvin Buckley <calvin@cmpct.info> wrote: > > > > On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> > wrote: > >> > >> Hi, > >> > >> During the discussion about the year 2038 issue it turned out > that maybe it's time to drop support for 32-bit of PHP completely. > >> > >> Based on that I have created an RFC to deprecate 32-bit build > in 8.next and drop support for it in 9. > >> > >> RFC: https://wiki.php.net/rfc/drop_32bit_support > > > > I think the biggest arguments against this would be: > > > > - embedded systems; think of PHP in use for i.e. router web UIs. > While I > > suspect a lot of these are going to be i.e. AArch64/RV64 in the > future, > > there might be a long tail of existing systems. Of course, how many > > would upgrade to PHP 9? > > > > - WebAssembly; I don't know how widespread the Memory64 proposal > is yet. > > We're using WebAssembly in the docs pages for runnable examples. > > > > And some niche cases like i.e. iSH (which emulates x86-32 on iOS). > > > > The other options include making zend_long always 64-bit and > accept the > > performance penalty for 32-bit, or making 32-bit best-effort > rather than > > providing any guarantees. > > > Last night, I was giving some thought to reviving Andrea’s Big > Integer RFC[^1]. This is something I’ve wanted for a long time > (especially for my ramsey/uuid library, among other things). > > Andrea had a work-in-progress PR[^2]. I’m not sure the current > state of it. It’s from 2014 and was originally written for phpng. > I had planned to start teasing out bits of it into a new branch > based on the current master branch to see how far I could get with > it. I wouldn’t mind some help with that, if anyone’s interested. :-) > > If we are able to finish what Andrea started, then we would not > need to drop support for 32bit builds. > > Cheers, > Ben > > > [^1]: https://wiki.php.net/rfc/bigint > [^2]: https://github.com/php/php-src/pull/876 > > > > > Smallest ramnode.com <http://ramnode.com> VPS has 512MB ram. I would > run 32bit PHP on a 512mb ram VPS. I'm not longer a ramnode customer, > but I used to be. > I for one would be sad to see 32bit PHP go.
I have done a quick test on current master with Symfony : Without OPCache x32: mem: 16777216b, t: 0.15017914772034s x64: mem: 23068672b, t: 0.072926998138428s With OPCache x32: mem: 4194304b, t: 0.01033878326416s x64: mem: 4194304b, t: 0.0080580711364746s As you can see, with opcache enabled it's taking the same amount of memory. (I don't know why ... did mostly the same setup as the configure-x32 GH action)

Hans Henrik Bergan

1 year ago
On Fri, 20 Jun 2025 at 13:20, Marc Bennewitz <marc@mabe.berlin> wrote:
> > > On 19.06.25 18:55, Hans Henrik Bergan wrote: > > On Thu, Jun 19, 2025, 18:24 Ben Ramsey <ramsey@php.net> wrote: >> >> > On Jun 19, 2025, at 11:08, Calvin Buckley <calvin@cmpct.info> wrote: >> > >> > On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> wrote: >> >> >> >> Hi, >> >> >> >> During the discussion about the year 2038 issue it turned out that maybe it's time to drop support for 32-bit of PHP completely. >> >> >> >> Based on that I have created an RFC to deprecate 32-bit build in 8.next and drop support for it in 9. >> >> >> >> RFC: https://wiki.php.net/rfc/drop_32bit_support >> > >> > I think the biggest arguments against this would be: >> > >> > - embedded systems; think of PHP in use for i.e. router web UIs. While I >> > suspect a lot of these are going to be i.e. AArch64/RV64 in the future, >> > there might be a long tail of existing systems. Of course, how many >> > would upgrade to PHP 9? >> > >> > - WebAssembly; I don't know how widespread the Memory64 proposal is yet. >> > We're using WebAssembly in the docs pages for runnable examples. >> > >> > And some niche cases like i.e. iSH (which emulates x86-32 on iOS). >> > >> > The other options include making zend_long always 64-bit and accept the >> > performance penalty for 32-bit, or making 32-bit best-effort rather than >> > providing any guarantees. >> >> >> Last night, I was giving some thought to reviving Andrea’s Big Integer RFC[^1]. This is something I’ve wanted for a long time (especially for my ramsey/uuid library, among other things). >> >> Andrea had a work-in-progress PR[^2]. I’m not sure the current state of it. It’s from 2014 and was originally written for phpng. I had planned to start teasing out bits of it into a new branch based on the current master branch to see how far I could get with it. I wouldn’t mind some help with that, if anyone’s interested. :-) >> >> If we are able to finish what Andrea started, then we would not need to drop support for 32bit builds. >> >> Cheers, >> Ben >> >> >> [^1]: https://wiki.php.net/rfc/bigint >> [^2]: https://github.com/php/php-src/pull/876 > > > > > Smallest ramnode.com VPS has 512MB ram. I would run 32bit PHP on a 512mb ram VPS. I'm not longer a ramnode customer, but I used to be. > I for one would be sad to see 32bit PHP go. > > I have done a quick test on current master with Symfony : > > Without OPCache > x32: mem: 16777216b, t: 0.15017914772034s > x64: mem: 23068672b, t: 0.072926998138428s > > With OPCache > x32: mem: 4194304b, t: 0.01033878326416s > x64: mem: 4194304b, t: 0.0080580711364746s > > As you can see, with opcache enabled it's taking the same amount of memory. (I don't know why ... did mostly the same setup as the configure-x32 GH action) >
the php memory allocator allocate large chunks from the OS, checking the OS-allocated memory doesn't tell the whole story, it's possible that the actual usage memory between 32/64 non-OPCache was minor, can you try: register_shutdown_function(function () { var_dump([ "memory_get_usage(real_usage:false)" => memory_get_usage(real_usage: false), "memory_get_usage(real_usage:true)" => memory_get_usage(real_usage: true), "memory_get_peak_usage(real_usage:false)" => memory_get_peak_usage(real_usage: false), "memory_get_peak_usage(real_usage:true)" => memory_get_peak_usage(real_usage: true), ]); });

Marc

1 year ago
On 20.06.25 14:21, Hans Henrik Bergan wrote:
> On Fri, 20 Jun 2025 at 13:20, Marc Bennewitz <marc@mabe.berlin> wrote: >> >> On 19.06.25 18:55, Hans Henrik Bergan wrote: >> >> On Thu, Jun 19, 2025, 18:24 Ben Ramsey <ramsey@php.net> wrote: >>>> On Jun 19, 2025, at 11:08, Calvin Buckley <calvin@cmpct.info> wrote: >>>> >>>> On Jun 19, 2025, at 11:08 AM, Marc Bennewitz <marc@mabe.berlin> wrote: >>>>> Hi, >>>>> >>>>> During the discussion about the year 2038 issue it turned out that maybe it's time to drop support for 32-bit of PHP completely. >>>>> >>>>> Based on that I have created an RFC to deprecate 32-bit build in 8.next and drop support for it in 9. >>>>> >>>>> RFC: https://wiki.php.net/rfc/drop_32bit_support >>>> I think the biggest arguments against this would be: >>>> >>>> - embedded systems; think of PHP in use for i.e. router web UIs. While I >>>> suspect a lot of these are going to be i.e. AArch64/RV64 in the future, >>>> there might be a long tail of existing systems. Of course, how many >>>> would upgrade to PHP 9? >>>> >>>> - WebAssembly; I don't know how widespread the Memory64 proposal is yet. >>>> We're using WebAssembly in the docs pages for runnable examples. >>>> >>>> And some niche cases like i.e. iSH (which emulates x86-32 on iOS). >>>> >>>> The other options include making zend_long always 64-bit and accept the >>>> performance penalty for 32-bit, or making 32-bit best-effort rather than >>>> providing any guarantees. >>> >>> Last night, I was giving some thought to reviving Andrea’s Big Integer RFC[^1]. This is something I’ve wanted for a long time (especially for my ramsey/uuid library, among other things). >>> >>> Andrea had a work-in-progress PR[^2]. I’m not sure the current state of it. It’s from 2014 and was originally written for phpng. I had planned to start teasing out bits of it into a new branch based on the current master branch to see how far I could get with it. I wouldn’t mind some help with that, if anyone’s interested. :-) >>> >>> If we are able to finish what Andrea started, then we would not need to drop support for 32bit builds. >>> >>> Cheers, >>> Ben >>> >>> >>> [^1]: https://wiki.php.net/rfc/bigint >>> [^2]: https://github.com/php/php-src/pull/876 >> >> >> >> Smallest ramnode.com VPS has 512MB ram. I would run 32bit PHP on a 512mb ram VPS. I'm not longer a ramnode customer, but I used to be. >> I for one would be sad to see 32bit PHP go. >> >> I have done a quick test on current master with Symfony : >> >> Without OPCache >> x32: mem: 16777216b, t: 0.15017914772034s >> x64: mem: 23068672b, t: 0.072926998138428s >> >> With OPCache >> x32: mem: 4194304b, t: 0.01033878326416s >> x64: mem: 4194304b, t: 0.0080580711364746s >> >> As you can see, with opcache enabled it's taking the same amount of memory. (I don't know why ... did mostly the same setup as the configure-x32 GH action) >> > the php memory allocator allocate large chunks from the OS, checking > the OS-allocated memory doesn't tell the whole story, > it's possible that the actual usage memory between 32/64 non-OPCache was minor, > can you try: > > register_shutdown_function(function () { > var_dump([ > "memory_get_usage(real_usage:false)" => > memory_get_usage(real_usage: false), > "memory_get_usage(real_usage:true)" => > memory_get_usage(real_usage: true), > "memory_get_peak_usage(real_usage:false)" => > memory_get_peak_usage(real_usage: false), > "memory_get_peak_usage(real_usage:true)" => > memory_get_peak_usage(real_usage: true), > ]); > }); >
                      X64 X32                      % t:                    0.005423069s    0.014256954s    262% mem:            1127808b            914064b              81% memReal:     4194304b           4194304b          100% peak:             1128696b           914888b              81% peakReal:     4194304b           4194304b           100% As you can see, the memory usage differences aren't that big but it's running much slower probably because of unavailable instruction sets on x32. Tested on Ubuntu 22.04 with i7-1165G7

Hans Henrik Bergan

1 year ago
On Mon, 23 Jun 2025 at 13:30, Marc Bennewitz <marc@mabe.berlin> wrote:
> > As you can see, the memory usage differences aren't that big but it's > running much slower probably because of unavailable instruction sets on x32. >
fwiw it's not the instruction set, it's mostly the registers, x86-64 have double the amount of general-purpose registers (8>16), thus less stack pushing/popping on x64.

Marc

1 year ago
On 19.06.25 18:08, Calvin Buckley wrote:
> I think the biggest arguments against this would be: > > - embedded systems; think of PHP in use for i.e. router web UIs. While I > suspect a lot of these are going to be i.e. AArch64/RV64 in the future, > there might be a long tail of existing systems. Of course, how many > would upgrade to PHP 9?
While new deployments trend toward 64-bit (e.g. AArch64), there's definitely a long list of devices — particularly in legacy environments — still running 32-bit systems. But realistically, how many of these will ever upgrade to PHP 9? Probably very few. These systems often stay locked to whatever version was originally shipped, and their vendors are unlikely to invest in major version bumps.
> - WebAssembly; I don't know how widespread the Memory64 proposal is yet. > We're using WebAssembly in the docs pages for runnable examples.
I don't know either. ChatGPT tells :
> The Memory64 proposal was *formally standardized (Phase 4)* in
November 2024, backed by strong votes and endorsement from the WASM Community Group.
> > It's enabled by default in *Firefox 134* and *Chrome 133+*, with
*Safari* still working on implementation.
> > Major runtimes like *V8*, *Wasmtime*, *Wasmer*, *WASM2C* support Memory64 > > Toolchains including *LLVM*, *Emscripten*, *Binaryen*, *WABT* support
it; *WASI‑SDK* has patches in progress
> And some niche cases like i.e. iSH (which emulates x86-32 on iOS).
This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons).
> The other options include making zend_long always 64-bit and accept the > performance penalty for 32-bit, or making 32-bit best-effort rather than > providing any guarantees.
Is int64_t (size of long long 8) available on all systems (like WebAssembly)? The downside here, please correct me if I'm wrong, is that this increases complexity instead of reducing it for how much value?

Hans Henrik Bergan

1 year ago
On Fri, 20 Jun 2025 at 09:15, Marc Bennewitz <marc@mabe.berlin> wrote:
> > > On 19.06.25 18:08, Calvin Buckley wrote: > > I think the biggest arguments against this would be: > > - embedded systems; think of PHP in use for i.e. router web UIs. While I > suspect a lot of these are going to be i.e. AArch64/RV64 in the future, > there might be a long tail of existing systems. Of course, how many > would upgrade to PHP 9? > > While new deployments trend toward 64-bit (e.g. AArch64), there's definitely a long list of devices — particularly in legacy environments — still running 32-bit systems. But realistically, how many of these will ever upgrade to PHP 9? Probably very few. These systems often stay locked to whatever version was originally shipped, and their vendors are unlikely to invest in major version bumps. > > - WebAssembly; I don't know how widespread the Memory64 proposal is yet. > We're using WebAssembly in the docs pages for runnable examples. > > I don't know either. ChatGPT tells : > > > The Memory64 proposal was formally standardized (Phase 4) in November 2024, backed by strong votes and endorsement from the WASM Community Group. > > > > It's enabled by default in Firefox 134 and Chrome 133+, with Safari still working on implementation. > > > > Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64 > > > > Toolchains including LLVM, Emscripten, Binaryen, WABT support it; WASI‑SDK has patches in progress > > > And some niche cases like i.e. iSH (which emulates x86-32 on iOS). > > This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons). > > The other options include making zend_long always 64-bit and accept the > performance penalty for 32-bit, or making 32-bit best-effort rather than > providing any guarantees. > > Is int64_t (size of long long 8) available on all systems (like WebAssembly)? > > The downside here, please correct me if I'm wrong, is that this increases complexity instead of reducing it for how much value?
>This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons).
3v4l.org use 32bit WASM php in production, see it for yourself at https://3v4l.org/

Marc

1 year ago
On 20.06.25 10:15, Hans Henrik Bergan wrote:
> On Fri, 20 Jun 2025 at 09:15, Marc Bennewitz<marc@mabe.berlin> wrote: >> >> On 19.06.25 18:08, Calvin Buckley wrote: >> >> I think the biggest arguments against this would be: >> >> - embedded systems; think of PHP in use for i.e. router web UIs. While I >> suspect a lot of these are going to be i.e. AArch64/RV64 in the future, >> there might be a long tail of existing systems. Of course, how many >> would upgrade to PHP 9? >> >> While new deployments trend toward 64-bit (e.g. AArch64), there's definitely a long list of devices — particularly in legacy environments — still running 32-bit systems. But realistically, how many of these will ever upgrade to PHP 9? Probably very few. These systems often stay locked to whatever version was originally shipped, and their vendors are unlikely to invest in major version bumps. >> >> - WebAssembly; I don't know how widespread the Memory64 proposal is yet. >> We're using WebAssembly in the docs pages for runnable examples. >> >> I don't know either. ChatGPT tells : >> >>> The Memory64 proposal was formally standardized (Phase 4) in November 2024, backed by strong votes and endorsement from the WASM Community Group. >>> >>> It's enabled by default in Firefox 134 and Chrome 133+, with Safari still working on implementation. >>> >>> Major runtimes like V8, Wasmtime, Wasmer, WASM2C support Memory64 >>> >>> Toolchains including LLVM, Emscripten, Binaryen, WABT support it; WASI‑SDK has patches in progress >> >> And some niche cases like i.e. iSH (which emulates x86-32 on iOS). >> >> This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons). >> >> The other options include making zend_long always 64-bit and accept the >> performance penalty for 32-bit, or making 32-bit best-effort rather than >> providing any guarantees. >> >> Is int64_t (size of long long 8) available on all systems (like WebAssembly)? >> >> The downside here, please correct me if I'm wrong, is that this increases complexity instead of reducing it for how much value? > >> This seems to be for very niche projects in itself already and running PHP within such is even more niche - if present at all (outside of "because I can" reasons). > 3v4l.org use 32bit WASM php in production, see it for yourself at > https://3v4l.org/
You misunderstood my sentence as I haven't told something else. My answer for the niche projects belongs to "... i.e. iSH (which emulates x86-32 on iOS)." About WebAssembly I wrote:

Hans Zaunere

1 year ago
Hello, my two cents, On Thu, Jun 19, 2025 at 9:09 PM Marc Bennewitz <marc@mabe.berlin> wrote:
> Hi, > > During the discussion about the year 2038 issue it turned out that maybe > it's time to drop support for 32-bit of PHP completely. > > Based on that I have created an RFC to deprecate 32-bit build in 8.next > and drop support for it in 9. > > RFC: https://wiki.php.net/rfc/drop_32bit_support
I'd hate to see PHP cut itself out of 32bit, especially with workloads getting device specific "on the edge", and heavy loads moving in to different components; the lightness of 32 IMHO will be an asset. I think too it'd put a burden on the tiny-container approach. Way back, we were excited <https://news-web.php.net/php.internals/12974> but most of it was Apache. I guess it'd be a drag to maintain two branches but maybe an option. To be honest, the only processes I see over 4gb, even these days, are browsers. :) Best, Hans

Marc

1 year ago
On 21.07.25 00:05, Hanz wrote:
> Hello, my two cents, > > On Thu, Jun 19, 2025 at 9:09 PM Marc Bennewitz <marc@mabe.berlin> wrote: > > Hi, > > During the discussion about the year 2038 issue it turned out that > maybe > it's time to drop support for 32-bit of PHP completely. > > Based on that I have created an RFC to deprecate 32-bit build in > 8.next > and drop support for it in 9. > > RFC: https://wiki.php.net/rfc/drop_32bit_support > > > I'd hate to see PHP cut itself out of 32bit, especially with workloads > getting device specific "on the edge", and heavy loads moving in to > different components; the lightness of 32 IMHO will be an asset.  I > think too it'd put a burden on the tiny-container approach.  Way back, > we were excited <https://news-web.php.net/php.internals/12974> but > most of it was Apache. > > I guess it'd be a drag to maintain two branches but maybe an option.  > To be honest, the only processes I see over 4gb, even these days, are > browsers. :)
I just send out an update, that - for now - I'll not continue on that RFC. Actually not because of "especially with workloads getting device specific 'on the edge'" because this is a niche case a vote should decide if it's worth it. I'm not sure what you mean with "tiny-container approach" and the old ML thread of supporting 64-bit builds but I hope I clarified this part already in my previous mail.
> Best, > Hans
Regards, Marc

Marc

1 year ago
Hi everyone, On 19.06.25 16:08, Marc Bennewitz wrote:
> Hi, > > During the discussion about the year 2038 issue it turned out that > maybe it's time to drop support for 32-bit of PHP completely. > > Based on that I have created an RFC to deprecate 32-bit build in > 8.next and drop support for it in 9. > > RFC: https://wiki.php.net/rfc/drop_32bit_support >
I’m writing to let you know that I’ve decided not to move forward with the RFC to drop 32-bit support - at least for now. While there are clear problems with continuing to support 32-bit PHP builds, such as: * additional complexity for the language itself and for library maintainers * Y2038 problem due to 32-bit integers used for Unix timestamps * File size limitations * Memory usage limitations * Issues with functions like |crc32|, |ip2long|, and |long2ip| returning negative values there are still some valid use cases that currently don’t have ready-to-use alternatives. The most significant of these identified is WebAssembly, which is actively used on for the PHP documentation and 3v4l.org. Although 64-bit WebAssembly support is nearly available in all major browsers, it’s still relatively new and not yet fully supported everywhere (Safari). Additionally, adopting 64-bit WebAssembly will require some effort from the affected projects. Other use cases are more on the edge, like slightly older routers, embedded systems, X86-32 emulators and others, but the listed drawbacks may outweigh the benefits of these niche cases. One argument I don’t consider strong is running 32bit builds of PHP on already supporting 64bit environments to save memory. While it's true, that 32-bit builds consumes less memory - it's actually not that much and it comes with a cost of being ~2.5 times slower.            X64           X32           % time:      0.005423069s  0.014256954s  262% mem:       1127808b       914064b       81% memReal:   4194304b      4194304b      100% peak:      1128696b       914888b       81% peakReal:  4194304b      4194304b      100% That said, once WebAssembly has been fully adopted, I'll most likely revisit this RFC. In the meantime, there are two possibilities to reduce the issues of 32-bit builds, though both would increase the complexity of PHP internals. * consistent 64-bit integers on all platforms [1] * native big integer support [2][3] [1] https://github.com/php/php-src/pull/19079 (Draft) [2] https://wiki.php.net/rfc/bigint (Withdrawn) [3] https://github.com/php/php-src/pull/876 (Closed)