Hi all,
On 16 Jun 2025, at 17:24, Rob Landers <rob@bottled.codes> wrote:
>
>
>
> On Mon, Jun 16, 2025, at 16:54, Alexandru Pătrănescu wrote:
>>
>>
>>
>> On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz <marc@mabe.berlin> wrote:
>> Hi all,
>>
>> It's 12.5 years only until the timestamps in PHP on 32bit will not work
>> as expected anymore.
>>
>>
>> Hi,
>>
>> I think that maybe we can already deprecate supporting 32 bit builds.
>> And, maybe with PHP 9, or PHP 10, or with a future version that might exist in about 6/7
>> years, completely drop 32 bits support.
>>
>> As far as I checked a bit, all major OSs where PHP could run already dropped or will drop
>> support for 32 bits builds.
>> I expect that at some point even the linux kernel will drop support.
>>
>> The impacted runtimes will probably be very low.
>>
>> --
>> Alex
>>
>
> 100% agree. We are already running out of space on some bitmasks (there are a couple with
> exactly one bit left, or even none in the case of GC flags) for 32 bit support.
>
> — Rob
I'm reminded of a recent comment by Derick. He mentioned that usually if a function can't
be provided on a specific platform or SAPI, that function is disabled for that environment
specifically. This allows for a polyfill to provide an alternative implementation. (e.g.
getallheaders())
Considering 32-bit builds will not be able to reliable provide the date() function at
some point, what if we deprecate, and later disable, these integer date functions on 32-bit builds
specifically? This would have 0 impact for 64-bit users and provide a means for users on legacy or
embedded systems to use an alternative implementation (that perhaps uses a custom Unix epoch, or
numeric strings ¯\_(ツ)_/¯).
Alwin