Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129405
Message-ID: <9b6665e9-7daa-4138-9e4d-180425cc7c8c@bastelstu.be>
Date: Sun, 23 Nov 2025 15:45:19 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Re: [RFC] Add pack()/unpack() support for signed
 integers with specific endianness
To: Alexandre Daubois <alex.daubois+php@gmail.com>,
 PHP internals list <internals@lists.php.net>
References: <CAMU7irLuV_CWR37odtuu0TL7io_bONy+5xebY82YnVb38RtEzg@mail.gmail.com>
 <CAMU7ir+0r1c86Z1YcHSLts15Nv2iQnHxcT1AO6K1FVt8PJDDLA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAMU7ir+0r1c86Z1YcHSLts15Nv2iQnHxcT1AO6K1FVt8PJDDLA@mail.gmail.com>
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

On 11/21/25 11:46, Alexandre Daubois wrote:
> After rereading the threads and spending some time thinking about it
> all, I propose a new version of this RFC aimed at adding Perl
> modifiers. Indeed, this seems to be a better solution than the one
> previously proposed, and several people seem to share this opinion.
> 
> The RFC URL is the same and its version has been bumped to 1.1:
> https://wiki.php.net/rfc/pack-unpack-endianness-signed-integers-support
> 
> Looking forward to reading your feedback on this revision.

Thank you.

I only have one comment on

> Initially, endianness modifiers will only be supported for signed integer format codes (s, l, q) since unsigned integers already have dedicated endian-specific letters.

While there are already dedicated alternatives, I feel that restricting 
the new modifiers to the lowercase versions would be unnecessarily 
restrictive. Since the RFC argues that:

> 2. Intuitive semantics: The < and > symbols visually suggest byte order direction

which I agree with, the same argument applies to the uppercase QLS 
versions. As a developer I would rather remember l> as "signed long 
big-endian" and L> as "unsigned long big-endian" rather than N as 
"4-byte network-byte order".

Since there is no inherent limitation or ambiguity with supporting 
modifiers on QLS, I would suggest just allowing it. In fact I think my 
PoC patch already supported them.

There's also a formatting issue of the “Rationale” in the “Proposed 
Solution” section.

Best regards
Tim Düsterhus