Re: [RFC] Add pack()/unpack() support for signed integers with specific endianness

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