Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128151
Precedence: bulk
MIME-Version: 1.0
References: <faff22ce-dcb9-4013-80d9-ceddd0de5a12@mabe.berlin>
In-Reply-To: <faff22ce-dcb9-4013-80d9-ceddd0de5a12@mabe.berlin>
Date: Mon, 21 Jul 2025 05:05:27 +0700
Message-ID: <CACGAZnJ7nEkP6crpJA840dxpf1mMZbnVj0bNS2sdYcaEGTL03A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Drop support for 32bit builds
To: Marc Bennewitz <marc@mabe.berlin>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002f7e4a063a638f89"
From: zaunere@gmail.com (Hanz)

--0000000000002f7e4a063a638f89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello, my two cents,

On Thu, Jun 19, 2025 at 9:09=E2=80=AFPM Marc Bennewitz <marc@mabe.berlin> w=
rote:

> Hi,
>
> 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.
>
> Based on that I have created an RFC to deprecate 32-bit build in 8.next
> and drop support for it in 9.
>
> RFC: https://wiki.php.net/rfc/drop_32bit_support


I'd hate to see PHP cut itself out of 32bit, especially with workloads
getting device specific "on the edge", and heavy loads moving in to
different components; the lightness of 32 IMHO will be an asset.  I think
too it'd put a burden on the tiny-container approach.  Way back, we were
excited <https://news-web.php.net/php.internals/12974> but most of it was
Apache.

I guess it'd be a drag to maintain two branches but maybe an option.  To be
honest, the only processes I see over 4gb, even these days, are browsers. :=
)

Best,

Hans

--0000000000002f7e4a063a638f89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hello, my two cents,</div><div><br><=
/div></div><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr=
" class=3D"gmail_attr">On Thu, Jun 19, 2025 at 9:09=E2=80=AFPM Marc Bennewi=
tz &lt;marc@mabe.berlin&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">Hi,<br>
<br>
During the discussion about the year 2038 issue it turned out that maybe <b=
r>
it&#39;s time to drop support for 32-bit of PHP completely.<br>
<br>
Based on that I have created an RFC to deprecate 32-bit build in 8.next <br=
>
and drop support for it in 9.<br>
<br>
RFC: <a href=3D"https://wiki.php.net/rfc/drop_32bit_support" rel=3D"norefer=
rer" target=3D"_blank">https://wiki.php.net/rfc/drop_32bit_support</a></blo=
ckquote><div><br></div><div>I&#39;d hate to see PHP cut itself out of 32bit=
, especially with workloads getting device specific &quot;on the edge&quot;=
, and heavy loads moving in to different components; the lightness of 32 IM=
HO will be an asset.=C2=A0 I think too it&#39;d put a burden on the tiny-co=
ntainer approach.=C2=A0 Way back, we were <a href=3D"https://news-web.php.n=
et/php.internals/12974">excited</a>=C2=A0but most of it was Apache.</div><d=
iv><br></div><div>I guess it&#39;d be a drag to maintain two branches but m=
aybe an option.=C2=A0 To be honest, the only processes I see over 4gb, even=
 these days, are browsers. :)</div><div><br></div><div>Best,</div><div><br>=
</div><div>Hans</div><div><br></div><div><br></div></div></div>

--0000000000002f7e4a063a638f89--