Are there plans for ending support for 32-bit php? (year 2038 problem)

On Fri, Jan 8, 2021 at 3:47 AM tyson andre tysonandre775@hotmail.com
wrote:

Hi internals,

1. In 2038, (new DateTime())->getTimestamp() and other time apis such as
   strtotime will start throwing "ValueError: Epoch doesn't fit in a PHP
   integer"
   on 32-bit php builds, where PHP's int type is 32-bits.
   (other APIs will return negative 32-bit integers)
   See https://en.wikipedia.org/wiki/Year_2038_problem
2. Because PHP provides security support for 3 years, and many *nix OS
   LTS releases extend it even longer, we should decide on what to do about
   32-bit support well before 2038 (drop it or implement alternatives, and
   alternatives seem unlikely to support a small fraction of hardware).
3. Needing to support 32-bit PHP builds limits the APIs that can be
   included in PHP, and slightly slows down development of PHP, PECLs, and
   composer packages.
4. I think PHP's documentation and tools should start discouraging
   deploying new 32-bit builds, and give advance notice that it would be
   removed (if it seems likely 32-bit support will be dropped.)

Repeating the above points in more detail,

1. In the year 2038, many of 32-bit php builds' APIs dealing with unix
   timestamps will stop working.
   E.g. in 2038 on a 32-bit build of php, (new DateTime())->getTimestamp()
   would throw "ValueError: Epoch doesn't fit in a PHP integer" instead of
   returning an int,
   when the time passes 0x7FFFFFFF. See https://bugs.php.net/bug.php?id=52062
   for details.
   I'd consider throwing in getTimestamp to be the most reasonable solution,
   given the return type of those methods is int, existing code may pass the
   return value
   to a function/property with real type int, etc.

https://www.drupal.org/docs/system-requirements/limitations-of-32-bit-php

2. Although php's security support for a minor release lasts for only 3
   years,
   some *nix OSes will make a best effort at unofficially backporting
   patches to php for the lifetime of that OS's LTS release,
   so we could potentially see 32-bit builds for ~10 years (not sure what
   32-bit distros there will be in 2028. This number is a guess.)

• on desktop oses, the main use of 32-bit packages on 64-bit hardware
  seems to be for supporting code released for only one architecture,
  e.g.
  https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
• Many WordPress servers still run php 5.x.
• If applications running on an OS with 10 years of php support computed
  dates that are a year in the future,
  it'd be useful to prepare 11 years in advance.
  There are 17 years until 2038.

Hardware that only has 32-bit support is still running on a small fraction
of machines being sold (e.g. cheap laptops),
and 32-bit hardware may last decades after they were manufactured,
but is hopefully a tiny fraction of server/consumer hardware still being
manufactured in 2021.
I don't know of 32-bit php running in embedded systems or IoT devices, but
haven't looked.

• Aside: It is possible to install a 32-bit only OS on hardware supporting
  64-bit architectures,
  https://www.backblaze.com/blog/64-bit-os-vs-32-bit-os/

If PHP's maintainers decide to drop support for 32-bit builds in a future
major/minor release, it would be useful to give users advance notice,
so that they can factor this into decisions on hardware and OSes to use
for deploying php in servers or developing locally.

3. Needing to support 32-bit PHP builds limits what can be done in the
   language, and slightly slows down development of PHP, PECLs, and composer
   packages.

Additionally, continuing to provide 32-bit support constrains what APIs
can be provided by the language.
In most cases this isn't an issue, but this came up with
PRNG->next64BitInt() being impractical practical in a recent proposal:
https://externals.io/message/112525#112722

• 32-bit installations do reduce the memory usage and installation size of
  php slightly,
  but those installations would have problems with the 2038 problem and
  supporting use cases that require more than 2-4GB of free memory.
• PECLs and composer packages are generally not tested as thoroughly on
  32-bit builds.
  Maintainers may be less responsive if they're personally unaffected, or
  don't already have 32-bit builds installed, or don't know from the bug
  report that 32-bit php was used.
• The PHP interpreter (Zend/zend_vm_def.h, etc.) and JIT have different
  implementations for 32-bit builds, complicating development of php itself.
  Hypothetically that could lead to bugs getting released and contributing
  to the VM being harder to do, but in practice it doesn't seem to be a large
  issue.

In comparison, other languages I've used would have an easier time
continuing to support 32-bit builds past 2038.

• Python and Ruby have arbitrary-precision numbers.
• In Java, int is 32-bit, and long is 64-bit.
• Golang and C and rust have int64_t and int32_t equivalents, but also
  support a separate int for the native word size.
• Javascript only has a Number type that is equivalent to 64-bit floats.
  JS also has a distinct BigInt object type for arbitrary precision numbers.

I'd considered some alternatives, but they didn't seem viable:
a. Changing the signature of getTimestamp(etc.) to int|float would cause
different issues once the floats were used and make static analysis harder

• applications may see obvious TypeErrors,
  or functions returning early for non-integers, or subtler issues with
  serializing data as an unexpected type

We have some database drivers that return int|string result to accommodate
either 32-bit systems, or 64-bit unsigned integers on 64-bit systems. It's
the best we can do right now, but it certainly makes for ugly type
signatures, and I agree that it would not be an adequate solution for
timestamps.

b. Using 64-bit integers for PHP's int type (zend_long) (but continuing
to use 32-bit pointers, etc.) for PHP's int didn't seem worth the effort
and bugs it may cause.
A lot of php internals or PECL code would implicitly assume that
sizeof(zend_long) <= sizeof(size_t), sizeof(void*) (etc.) and I'd expect
changing that to lead to too many bugs to be worth it.

When run on 64-bit systems, this is known as the x32 ABI. While PHP does
not officially support running in this configuration, it does mostly work
fine. Of course, doing the same on a 32-bit system is more problematic --
for performance reasons if nothing else. I don't think anyone has tried
doing this yet.

The option c) that you don't mention is to make integers arbitrary
precision, with fast-paths for either 32-bit or 64-bit integers, depending
on platform. Of course, this is also not quite easy :)

Finally, some people would argue that if you're using timestamps you are
doing it wrong anyway. If you stick with DateTimes, then you don't have a
problem (or do you?)

Overall I'm not really sure what to think about this. I personally don't
have any idea how common PHP is used on 32-bit systems (are there any stats
on that? From OS package installs, composer, etc?) and why it is used
there. I know that running PHP on 32-bit is often faster, but I'm not sure
if people explicitly chose to use 32-bit for that reason.

Regards,
Nikita

4. I have some modest proposals for discouraging the deployment of 32-bit

PHP builds before they are removed (if 32 bit builds do get removed):

If the PHP project's leaders or core developers don't have objections to
dropping 32-bit support:

a. Decide whether to postpone making a decision, or decide on an
approximate year or release to announce that the php project would drop
32-bit support and document that.
to give users and package maintainers advance time to prepare. (e.g.
for developers to choose their next computer purchase, avoid hypothetically
selling embedded 32-bit hardware with 32-bit php installed, or setting up
new servers or shared hosting on 32-bit hardware)
b. Optionally, visually emphasize 64-bit downloads of PHP on the windows
download page to make the recommended version obvious to users unfamiliar
with the difference between x64 and x86 builds,
similar to how https://golang.org/dl/ highlights 64-bit builds in bold.
(e.g. on https://windows.php.net/download/ , use fainter text color,
mention that most use cases use x64, and optionally mention how to check if
the OS is 32-bit Windows)
c. In parts of php that would not affect typical PHP applications or
servers, mention (when run under 32-bit builds) that 32-bit builds of php
may break in 2038 and that users should migrate before then
(e.g., php -a, php --version, php --help, ./configure, pecl,
near the top of phpinfo())

The last time I saw the year 2038 problem mentioned on php-internals was
tangentially, in 2014:
https://marc.info/?l=php-internals&m=140558153213332&w=2

Thanks,

• Tyson