PHP RFC: Drop 32-bit Builds

• Version: 0.9
• Date: 2025-06-18
• Author: Marc Bennewitz, marc@mabe.berlin
• Status: Draft
• First Published at: https://wiki.php.net/rfc/drop_32bit_support

Historically, PHP has supported both 32-bit and 64-bit environments. However, the vast majority of production deployments now use 64-bit systems. Major operating systems and distributions have either already dropped support for 32-bit architectures or are in the process of doing so. Maintaining 32-bit compatibility incurs development, testing, and ongoing maintaining overhead.

32-bit environments have known limitations especially because PHP's int type being a platform-dependent signed integer. This restricts values to a range between -2,147,483,648 and 2,147,483,647. This constraint leads to several problems:

In PHP, UNIX timestamps are defined as signed integers and used very often all over the place resulting in a limited range of 1901-12-13 20:45:52 UTC to 2038-01-19 03:14:07 UTC.

The only exception is the DateTime[Immutable] class, which internally uses int64_t, which avoids this issue. However, using them as a workaround is risky and error-prone, especially since not all timestamp-related methods (e.g., DateTimeInterface::[get|set]Timestamp()) support full 64-bit behavior on 32-bit builds.

Additionally, other extensions rely on the UNIX timestamps as well and as such will be not fully functional (e.g. timestamps in opcache_get_status()).

On 32-bit builds, PHP can handle files up-to 2g only. This includes file streams as well.

On 32-bit builds, the PHP process is limited to 2g memory. Even on 32-bit builds on 64-bit systems resulting in mmap() failed: Cannot allocate memory + OOM Error.

Internals like opcodes, flag fields, and handlers are constrained by 32-bit word sizes, making certain optimizations or future extensions infeasible or hacky.

• crc32(): On 32-bit systems, many checksum results appear as negative integers. On 64-bit systems, all results are positive.
• ip2long()/long2ip(): many IP addresses will result in negative integers on 32-bit environments.

Most major platforms and Linux distributions have already ended support for 32-bit installations, though some still allow building and running 32-bit applications on 64-bit kernels.

Deprecate 32-bit support in the next minor release (PHP 8.x). Completely drop 32-bit support in the next major release (PHP 9.0).

Starting with PHP 9.0, it will no longer be possible to build or run PHP on 32-bit environments.

Beginning with PHP 9.0, PHP will no longer support 32-bit builds. Attempting to compile or run PHP in such environments will fail.

• PHP 8.x: Deprecate 32-bit support. Optionally warn users through deprecation notices.
• PHP 9.0: Fully remove support for 32-bit environments.

This RFC makes it impossible to build or run PHP on 32-bit-only platforms starting with PHP 9.0.

Also, it will not be possible to build PHP with 32-bit on 64-bit kernels.

Is it enough to inform users about this deprecation in the documentation or should the next minor release explicitly emit deprecation warnings when running or building on 32-bit builds?

64-bit builds will remain fully supported and unaffected by this change.

This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

This requires a 2/3 majority. It is straight Yes/No vote to accepting the RFC.

Links to any external patches and tests go here.

If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.

Make it clear if the patch is intended to be the final patch, or is just a prototype.

For changes affecting the core language, you should also provide a patch for the language specification.

After the project is implemented, this section should contain

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.