Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112808
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: Are there plans for ending support for 32-bit php? (year 2038
 problem)
Thread-Index: AQHW5QQBTX/TWSRVNESaGhAznNvRyQ==
Date: Fri, 8 Jan 2021 02:46:34 +0000
Message-ID:
 <DM6PR07MB66183D60F5B7F90AD2974099F9AF0@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: acf3164a-e19a-4270-e3cf-08d8b37f9ca1
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2021 02:46:34.2079
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM11HT091
Subject: Are there plans for ending support for 32-bit php? (year 2038
 problem)
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
1. In 2038, `(new DateTime())->getTimestamp()` and other time apis such as =
strtotime will start throwing "ValueError: Epoch doesn't fit in a PHP integ=
er"=0A=
   on 32-bit php builds, where PHP's `int` type is 32-bits.=0A=
   (other APIs will return negative 32-bit integers)=0A=
   See https://en.wikipedia.org/wiki/Year_2038_problem=0A=
2. Because PHP provides security support for 3 years, and many `*nix` OS LT=
S releases extend it even longer, we should decide on what to do about=0A=
   32-bit support well before 2038 (drop it or implement alternatives, and =
alternatives seem unlikely to support a small fraction of hardware).=0A=
3. Needing to support 32-bit PHP builds limits the APIs that can be include=
d in PHP, and slightly slows down development of PHP, PECLs, and composer p=
ackages.=0A=
4. I think PHP's documentation and tools should start discouraging deployin=
g new 32-bit builds, and give advance notice that it would be removed (if i=
t seems likely 32-bit support will be dropped.)=0A=
=0A=
Repeating the above points in more detail,=0A=
=0A=
1) In the year 2038, many of 32-bit php builds' APIs dealing with unix time=
stamps will stop working.=0A=
E.g. in 2038 on a 32-bit build of php, `(new DateTime())->getTimestamp()` w=
ould throw "ValueError: Epoch doesn't fit in a PHP integer" instead of retu=
rning an int,=0A=
when the time passes 0x7FFFFFFF. See=A0https://bugs.php.net/bug.php?id=3D52=
062 for details.=0A=
I'd consider throwing in getTimestamp to be the most reasonable solution, g=
iven the return type of those methods is `int`, existing code may pass the =
return value=0A=
to a function/property with real type int, etc.=0A=
=0A=
- https://www.drupal.org/docs/system-requirements/limitations-of-32-bit-php=
=0A=
=0A=
2) Although php's security support for a minor release lasts for only 3 yea=
rs,=0A=
some `*nix` OSes will make a best effort at unofficially backporting patche=
s to php for the lifetime of that OS's LTS release,=0A=
so we could potentially see 32-bit builds for ~10 years (not sure what 32-b=
it distros there will be in 2028. This number is a guess.)=0A=
- on **desktop** oses, the main use of 32-bit packages on 64-bit hardware s=
eems to be for supporting code released for only one architecture,=0A=
  e.g. https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu=
-19-10-and-20-04-lts=0A=
- Many WordPress servers still run php 5.x.=0A=
- If applications running on an OS with 10 years of php support computed da=
tes that are a year in the future,=0A=
  it'd be useful to prepare 11 years in advance.=0A=
  There are 17 years until 2038.=0A=
=0A=
Hardware that only has 32-bit support is still running on a small fraction =
of machines being sold (e.g. cheap laptops),=0A=
and 32-bit hardware may last decades after they were manufactured,=0A=
but is hopefully a tiny fraction of server/consumer hardware still being ma=
nufactured in 2021.=0A=
I don't know of 32-bit php running in embedded systems or IoT devices, but =
haven't looked.=0A=
- 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=
/=0A=
=0A=
If PHP's maintainers decide to drop support for 32-bit builds in a future m=
ajor/minor release, it would be useful to give users advance notice,=0A=
so that they can factor this into decisions on hardware and OSes to use for=
 deploying php in servers or developing locally.=0A=
=0A=
3) Needing to support 32-bit PHP builds limits what can be done in the lang=
uage, and slightly slows down development of PHP, PECLs, and composer packa=
ges.=0A=
=0A=
Additionally, continuing to provide 32-bit support constrains what APIs can=
 be provided by the language.=0A=
In most cases this isn't an issue, but this came up with `PRNG->next64BitIn=
t()` being impractical practical in a recent proposal: https://externals.io=
/message/112525#112722=0A=
=0A=
- 32-bit installations do reduce the memory usage and installation size of =
php slightly,=0A=
  but those installations would have problems with the 2038 problem and sup=
porting use cases that require more than 2-4GB of free memory.=0A=
- PECLs and composer packages are generally not tested as thoroughly on 32-=
bit builds.=0A=
  Maintainers may be less responsive if they're personally unaffected, or d=
on't already have 32-bit builds installed, or don't know from the bug repor=
t that 32-bit php was used.=0A=
- The PHP interpreter (Zend/zend_vm_def.h, etc.) and JIT have different imp=
lementations for 32-bit builds, complicating development of php itself.=0A=
  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.=0A=
=0A=
In comparison, other languages I've used would have an easier time continui=
ng to support 32-bit builds past 2038.=0A=
=0A=
- Python and Ruby have arbitrary-precision numbers.=0A=
- In Java, `int` is 32-bit, and `long` is 64-bit.=0A=
- Golang and C and rust have `int64_t` and `int32_t` equivalents, but also =
support a separate `int` for the native word size.=0A=
- 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.=
=0A=
=0A=
I'd considered some alternatives, but they didn't seem viable:=0A=
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,=0A=
   or functions returning early for non-integers, or subtler issues with se=
rializing data as an unexpected type=0A=
b. Using 64-bit integers for PHP's int type (`zend_long`) (but continuing t=
o use 32-bit pointers, etc.) for PHP's `int` didn't seem worth the effort a=
nd bugs it may cause.=0A=
   A lot of php internals or PECL code would implicitly assume that `sizeof=
(zend_long) <=3D sizeof(size_t), sizeof(void*)` (etc.) and I'd expect chang=
ing that to lead to too many bugs to be worth it.=0A=
=0A=
4) I have some modest proposals for discouraging the deployment of 32-bit P=
HP builds before they are removed (if 32 bit builds do get removed):=0A=
=0A=
If the PHP project's leaders or core developers don't have objections to dr=
opping 32-bit support:=0A=
=0A=
a. Decide whether to postpone making a decision, or decide on an approximat=
e year or release to announce that the php project would drop 32-bit suppor=
t and document that.=0A=
   to give users and package maintainers advance time to prepare. (e.g. for=
 developers to choose their next computer purchase, avoid hypothetically se=
lling embedded 32-bit hardware with 32-bit php installed, or setting up new=
 servers or shared hosting on 32-bit hardware)=0A=
b. Optionally, visually emphasize 64-bit downloads of PHP on the windows do=
wnload page to make the recommended version obvious to users unfamiliar wit=
h the difference between x64 and x86 builds,=0A=
   similar to how https://golang.org/dl/ highlights 64-bit builds in bold.=
=0A=
   (e.g. on https://windows.php.net/download/ , use fainter text color, men=
tion that most use cases use x64, and optionally mention how to check if th=
e OS is 32-bit Windows)=0A=
c. In parts of php that would not affect typical PHP applications or server=
s, mention (when run under 32-bit builds) that 32-bit builds of php may bre=
ak in 2038 and that users should migrate before then=0A=
   (e.g., `php -a`, `php --version`, `php --help`, `./configure`, `pecl`,  =
near the top of `phpinfo()`)=0A=
=0A=
The last time I saw the year 2038 problem mentioned on php-internals was ta=
ngentially, in 2014: https://marc.info/?l=3Dphp-internals&m=3D1405581532133=
32&w=3D2=0A=
=0A=
Thanks,=0A=
- Tyson=0A=