Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127725
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Subject: Re: [PHP-DEV] [RFC] Drop support for 32bit builds
In-Reply-To: <faff22ce-dcb9-4013-80d9-ceddd0de5a12@mabe.berlin>
Date: Thu, 19 Jun 2025 13:08:06 -0300
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <73D7B135-ABF8-4EFC-BF16-EA26A5BD1B7A@cmpct.info>
References: <faff22ce-dcb9-4013-80d9-ceddd0de5a12@mabe.berlin>
To: Marc Bennewitz <marc@mabe.berlin>
From: calvin@cmpct.info (Calvin Buckley)

On Jun 19, 2025, at 11:08=E2=80=AFAM, Marc Bennewitz <marc@mabe.berlin> =
wrote:
>=20
> Hi,
>=20
> During the discussion about the year 2038 issue it turned out that =
maybe it's time to drop support for 32-bit of PHP completely.
>=20
> Based on that I have created an RFC to deprecate 32-bit build in =
8.next and drop support for it in 9.
>=20
> RFC: https://wiki.php.net/rfc/drop_32bit_support

I think the biggest arguments against this would be:

- embedded systems; think of PHP in use for i.e. router web UIs. While I
suspect a lot of these are going to be i.e. AArch64/RV64 in the future,
there might be a long tail of existing systems. Of course, how many
would upgrade to PHP 9?

- WebAssembly; I don't know how widespread the Memory64 proposal is yet.
We're using WebAssembly in the docs pages for runnable examples.

And some niche cases like i.e. iSH (which emulates x86-32 on iOS).

The other options include making zend_long always 64-bit and accept the
performance penalty for 32-bit, or making 32-bit best-effort rather than
providing any guarantees.=