Re: [PHP-DEV] Are there plans for ending support for 32-bit php? (year 2038 problem)
On Fri, Jan 8, 2021 at 3:47 AM tyson andre 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 0x7FFF. 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
[PHP-DEV] Are there plans for ending support for 32-bit php? (year 2038 problem)
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 0x7FFF. 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
