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

Hi

Am 2025-09-16 16:10, schrieb Alexandre Daubois:

seems. I guess it would be better to have dedicated functions. I don't
think it should be included in this RFC, but that is an interesting
idea nevertheless. I'd be really interested if someone comes up with
an RFC for this feature!

A better pack() with a streamlined format “description” would probably
fit with Ignace's proposed new Encoding extension:
https://externals.io/message/127716#127716

Best regards
Tim Düsterhus

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

$packed = pack("NNN", 123, 456, 789);
($x, $y, $z) = unpack("NNN", $packed);

$packed = pack("NNN", 123, 456, 789);
[$x, $y, $z] = unpack("NNN", $packed);

["x" => $x, "y" => $y, "z" => $z] = unpack("Nx/Ny/Nz", $packed);

Hi Tim,

I will vote against the RFC in its current state for the reasons that I
outlined before.

Given the previous exchanges, I totally get it. Thank you for taking
time to discuss this topic!

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.

I reworked the wording a bit and labeled the implementation as
"proposed PR" instead of "current PR" to reduce potential confusion.

Best,

— Alexandre Daubois

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

We do use lowercase/uppercase as an indicator for BE/LE for float specifiers, something Perl does not support.
However, the h (and b in Perl) specifiers use the case to indicate if it is the low or high nibble first.
Moreover, Perl and PHP primarily use cases to distinguish between signed and unsigned for integer specifiers, namely the s, l, q, i (and j for Perl) specifiers.
Only the n and v specifiers use uppercase to mean 32 bit instead of 16.
So there isn't a true "meaning" behind what upper and lowercase means, be that in Perl or in PHP.

While the < > syntax to "force" the endianess of a sequence specifier is nice.
But if this requires rewriting the whole parser as this RFC implies, then you are asking someone to commit to a larger amount of work than they signed up, which is considered bad RFC etiquette. [1]
Still stating your reason for rejecting an RFC is a nice heads up.

The strongest argument for introducing the < and > specifiers is that Python [2] does it that way, but a key distinction is that it is the only way to specify endianess.
And if this would be a new parser/API we might as well do other changes such as using a + or - specifier to indicate signedness, and add grouping using () like Perl.

Overall I am +-0 on this RFC because I don't use those functions, so I'll abstain from it.

Best regards,

Gina P. Banyard

[1] https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md#dont-volunteer-other-people-for-huge-amounts-of-work
[2] https://docs.python.org/3/library/struct.html#struct-alignment

 <?php

 var_dump(bin2hex(pack('s<2s>2', 258, -2, 258, -2)));
 var_dump(bin2hex(pack('a>', 258)));

 php > var_dump(pack('?', 123));
 PHP Warning:  Uncaught ValueError: Type ?: unknown format code in 

Hi

Hi

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.

I agree with Tim here and have a follow up question ...

Quoting the docs from Perl, it's also supported to use <> modifiers on
floating point values but I haven't found any note about it in your RFC.
In my opinion it makes sense to allow these modifiers on fd as well for
the same reasons as QLS.

• Also floating point numbers have endianness. Usually (but not
  always) this agrees with the integer endianness. Even though most
  platforms these days use the IEEE 754 binary format, there are
  differences, especially if the long doubles are involved. You can see
  the |Config| variables |doublekind| and |longdblkind| (also
  |doublesize|, |longdblsize|): the "kind" values are enums, unlike
  |byteorder|. Portability-wise the best option is probably to keep to the
  IEEE 754 64-bit doubles, and of agreed-upon endianness. Another
  possibility is the |"%a"|) format of |printf|
  https://perldoc.perl.org/functions/printf.
• Starting with Perl 5.10.0, integer and floating-point formats,
  along with the |p| and |P| formats and |()| groups, may all be followed
  by the |>| or |<| endianness modifiers to respectively enforce big- or
  little-endian byte-order. These modifiers are especially useful given
  how |n|, |N|, |v|, and |V| don't cover signed integers, 64-bit integers,
  or floating-point values.

<snip> > * Real numbers (floats and doubles) are in native machine format only. Due to the multiplicity of floating-point formats and the lack of a standard "network" representation for them, no facility for interchange has been made. This means that packed floating-point data written on one machine may not be readable on another, even if both use IEEE floating-point arithmetic (because the endianness of the memory representation is not part of the IEEE spec). See also perlport <https://perldoc.perl.org/perlport>;. If you know /exactly/ what you're doing, you can use the |>| or |<| modifiers to force big- or little-endian byte-order on floating-point values.

Hi Tim,

Le dim. 23 nov. 2025 à 15:45, Tim Düsterhus tim@bastelstu.be a écrit :

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.

I agree. I just updated the text and tables to reflect the addition of
big and little endian unsigned integers throughout the document.

There's also a formatting issue of the “Rationale” in the “Proposed
Solution” section.

The text has been cleaned and simplified. Thanks!

— Alexandre Daubois