Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128708
Precedence: list
MIME-Version: 1.0
Date: Tue, 16 Sep 2025 17:39:24 +0200
To: Alexandre Daubois <alex.daubois+php@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Add pack()/unpack() support for signed integers
 with specific endianness
In-Reply-To: <CAMU7irKbh-1ExY0sUsM8m5npKe_bcVYPcr62DG+M7C2vP2eNmw@mail.gmail.com>
References: <CAMU7irLuV_CWR37odtuu0TL7io_bONy+5xebY82YnVb38RtEzg@mail.gmail.com>
 <e019e5c8feccbb4586153d7d93db2aec@bastelstu.be>
 <CAMU7irKbh-1ExY0sUsM8m5npKe_bcVYPcr62DG+M7C2vP2eNmw@mail.gmail.com>
Message-ID: <eab4a39430e842368ec54b4c56595dbb@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-09-16 16:50, schrieb Alexandre Daubois:
> Indeed, it is just that I'm not sure that it is worth adding modifiers
> support to pack and unpack as with this addition, most (if not all)
> cases should be covered then.

I don't think it is worth blocking more letters that are also 
incompatible with the language where pack() was “borrowed” from.

>> This is simply false. v/n/V/N identically exist in Perl. J is not 
>> clear
>> to me, and P appears to be different (but I don't do enough Perl to 
>> say
>> for certain).
> 
> Perl and PHP share common letters, you are right. But looking at the

They don't just “share common letters”. The pack() function is directly 
coming from Perl and that is also documented:

> The idea for this function was taken from Perl and all formatting codes 
> work the same as in Perl. However, there are some formatting codes that 
> are missing such as Perl's "u" format code.

.

> table of each language, there are many differences. However, I may
> reword it as I realized that the RFC states that differences appear
> with specific endianness letters (and you showed that it's not true).
> There are many differences when we're not talking about endian
> specific formats actually.

I'm not sure if “all formatting codes work the same” is still 100% 
accurate (due to J and P), but “many differences” is definitely false. 
I'm seeing the following differences:

- J and P might or might not be different.
- e, E, g, and G don't exist in Perl (it would be d<, d>, f<, and f> 
respectively; these format specifiers could be deprecated if this RFC 
ships).

Both w and W are already taken in Perl and would actually be a 
difference.

Best regards
Tim Düsterhus