Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129021
Precedence: list
MIME-Version: 1.0
Date: Fri, 31 Oct 2025 12:07:56 +0100
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [RFC] Add pack()/unpack() support for signed
 integers with specific endianness
In-Reply-To: <CAMU7irLP0LHZzzkgXywBjp_Gp1_2rHY-erg85y4ahStOoWZZTQ@mail.gmail.com>
References: <CAMU7irLuV_CWR37odtuu0TL7io_bONy+5xebY82YnVb38RtEzg@mail.gmail.com>
 <CAMU7irLP0LHZzzkgXywBjp_Gp1_2rHY-erg85y4ahStOoWZZTQ@mail.gmail.com>
Message-ID: <86c27cd68c8ba8056d832a845eb15dcd@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-10-31 10:29, schrieb Alexandre Daubois:
> If no concerns are raised in the next few days, I'll open this RFC to
> the vote in its current state.

I will vote against the RFC in its current state for the reasons that I 
outlined before.

It's needlessly diverging from Perl by inventing new letters that are 
not even internally consistent with the existing letters (lowercase vs 
uppercase is 16 bit vs 32 bit, not LE vs BE). It is also still making 
the false statement that Perl's approach doesn't work for PHP when we 
established during the discussion that it does work, if we want it to 
work. It's also needlessly confusing the reader by including information 
about a PR #19368 implementation that can easily be mistaken for 
something that is already an established fact rather than a proposal.

Best regards
Tim Düsterhus