Hi
On 23.11.25 15:45, Tim Düsterhus wrote:
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.
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.
