Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129028
Precedence: list
MIME-Version: 1.0
References: <CAMU7irLuV_CWR37odtuu0TL7io_bONy+5xebY82YnVb38RtEzg@mail.gmail.com>
 <CAMU7irLP0LHZzzkgXywBjp_Gp1_2rHY-erg85y4ahStOoWZZTQ@mail.gmail.com> <86c27cd68c8ba8056d832a845eb15dcd@bastelstu.be>
In-Reply-To: <86c27cd68c8ba8056d832a845eb15dcd@bastelstu.be>
Date: Fri, 31 Oct 2025 14:27:52 +0100
Message-ID: <CAMU7irLUBcRrXk9mmGK2TB6uCiviY+Qmxi16gfy33ZbpZKvJKw@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] Add pack()/unpack() support for signed
 integers with specific endianness
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: alex.daubois+php@gmail.com (Alexandre Daubois)

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,

=E2=80=94 Alexandre Daubois