Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129053
Date: Mon, 03 Nov 2025 14:51:23 +0000
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Alexandre Daubois <alex.daubois+php@gmail.com>, PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [RFC] Add pack()/unpack() support for signed integers with specific endianness
Message-ID: <nTMJmPptsOwV9oUvFHMVGdhRXwVQfulxm5r8se3cReGLgjL4OZO48hzZmytxUnDvMto_2EpQGB42dUOR4a3IwjjNRxAwFOJkxsEQne1vW3s=@gpb.moe>
In-Reply-To: <86c27cd68c8ba8056d832a845eb15dcd@bastelstu.be>
References: <CAMU7irLuV_CWR37odtuu0TL7io_bONy+5xebY82YnVb38RtEzg@mail.gmail.com> <CAMU7irLP0LHZzzkgXywBjp_Gp1_2rHY-erg85y4ahStOoWZZTQ@mail.gmail.com> <86c27cd68c8ba8056d832a845eb15dcd@bastelstu.be>
Feedback-ID: 96993444:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Friday, 31 October 2025 at 11:11, Tim D=C3=BCsterhus <tim@bastelstu.be> =
wrote:

> Hi
>=20
> Am 2025-10-31 10:29, schrieb Alexandre Daubois:
>=20
> > If no concerns are raised in the next few days, I'll open this RFC to
> > the vote in its current state.
>=20
>=20
> I will vote against the RFC in its current state for the reasons that I
> outlined before.
>=20
> 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.
>=20
> Best regards
> Tim D=C3=BCsterhus

We do use lowercase/uppercase as an indicator for BE/LE for float specifier=
s, 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 an=
d unsigned for integer specifiers, namely the s, l, q, i (and j for Perl) s=
pecifiers.
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 t=
hat in Perl or in PHP.

While the < > syntax to "force" the endianess of a sequence specifier is ni=
ce.
But if this requires rewriting the whole parser as this RFC implies, then y=
ou 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 Pytho=
n [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 suc=
h as using a + or - specifier to indicate signedness, and add grouping usin=
g () like Perl.

Overall I am +-0 on this RFC because I don't use those functions, so I'll a=
bstain 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