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

On Mon, Nov 3, 2025, at 17:09, Tim Düsterhus wrote: > Hi > > Am 2025-11-03 15:51, schrieb Gina P. Banyard: > > 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] > > I disagree with that claim in the RFC and to put my money where my mouth > is, I have spent the 15 minutes of writing the necessary patch for the > pack() function. It is attached to this email and also available as this > gist: > https://gist.github.com/TimWolla/d8bca56a6507226e684827d2a7b44829. > Given the time spent, I've only given it light testing, but it passes > all existing pack() tests and returns the correct output for: > > <?php > > var_dump(bin2hex(pack('s<2s>2', 258, -2, 258, -2))); > var_dump(bin2hex(pack('a>', 258))); > > Using perl -e "print pack('s<2s>2', 258, -2, 258, > -2)" |xxd as a > comparison. I have not created the patch for unpack(), but I > believe > this is already sufficient demonstration that “rewriting the whole > parser” is not necessary at all. > > Best regards > Tim Düsterhus > > *Attachments:* > • 0001-pack-Support-endian-specifier.patch Please don’t do this. For those of us using pack()/unpack(), I don’t really care how much like or unlike Perl it is, and having to switch strings based on php version because someone wanted it like Perl sounds like a special kind of hell. It’s already tricky enough to get pack/unpack right when dealing with binary data and having to do it twice plus maintain two different versions of the same string… no thank you. It’s also used subtly in all kinds of unexpected places (totp calculations, encryption polyfills, etc). This kind of change would almost necessitate a major version bump of php. — Rob