Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112812 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 60883 invoked from network); 8 Jan 2021 09:50:36 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Jan 2021 09:50:36 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 962FF1804D1 for ; Fri, 8 Jan 2021 01:27:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 8 Jan 2021 01:27:31 -0800 (PST) Received: by mail-lf1-f52.google.com with SMTP id s26so21353585lfc.8 for ; Fri, 08 Jan 2021 01:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xYCYxxurLF1340q+HkRqQ1LReKZ1E9sXWH8G9IqDUSg=; b=K1dFLaG+4I5nxip+EvI7HCcXn1XBBCcrrO7ox7fikovaCiw+gKjLqkxQfuBVLAoBT+ WE+2K8MOPA2VkP/CGlulQCMXQkb6WiZbIRAuR5KszFoo4WVZ6vC5PUQsHpA02gSP3fU5 yuEh46xJxZybDYMy9J+rM6N3ywNtegaSbfpfCv9oHvKw4Gla6N1DBd3eXfzbNIta47MW zuWVlaFkc1lLKBHzLlQOl8D/n/Gz9eeulPcyH1XmuvCTrdcYlLY7e3BQhSg8XcmsgVfC gU7pNO+h/bV/8Hfgm8GG+MEjHT6DE7vDpbvdCIPHraykIqQk0Ty8mwtPRn5zzxZSEmf2 fYeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xYCYxxurLF1340q+HkRqQ1LReKZ1E9sXWH8G9IqDUSg=; b=V0dN9zUtdMuHSsuxaTUdPiRnSoszOulwPpA14cz/59NJJcBdenuENu7nypNy5IVCDi U/k/ovrEwXjqMsdgX4fAEsNZxv+64r++klLYesLr1+4GyAwDqC6y36Q6hq5cA/f+4T0k vcJ5mAlWp+PM73fEaH9YKYMZ83c82VFc0135G45S38882XOFITuDf2mzi1s+xQHJfTSz 0wfqPgC45dF9lDNJeLDemgNkiyPCqggGxuKZ9XtdmBmQqH+O2w4ekdixUftR0Ur0iiQe KxZDnqhEv56hWwQNjbsXlOr9w1Bj05jFv25rB4CZxiDpC28Iu7Rdzv97xZvXfjkP6qAs +vwg== X-Gm-Message-State: AOAM532s47e17TF1olHvhAeat+VFrEmyJh52DuGJpgOM2PL80ihLmI0w BWlQI9vJkd+Href7GmD48ZadVb60jwaV0Lj6rkY= X-Google-Smtp-Source: ABdhPJwUvPR+pdMpQ1D4ndbkvzv2zr7aZzgC8SZzxVdP4AitjzKUPDnSUIwOIAPFYOwscd/jblV1KRYLeOl2vKZ2WEc= X-Received: by 2002:ac2:4431:: with SMTP id w17mr1183431lfl.223.1610098047358; Fri, 08 Jan 2021 01:27:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 8 Jan 2021 10:27:11 +0100 Message-ID: To: tyson andre Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary="0000000000002a9ce105b8602ab5" Subject: Re: [PHP-DEV] Are there plans for ending support for 32-bit php? (year 2038 problem) From: nikita.ppv@gmail.com (Nikita Popov) --0000000000002a9ce105b8602ab5 Content-Type: text/plain; charset="UTF-8" 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 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 > --0000000000002a9ce105b8602ab5--