Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129057
Message-ID: <3a833bdd-91d6-4af2-a465-c1ccc1653e22@gmail.com>
Date: Mon, 3 Nov 2025 18:50:15 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Re: [RFC] Add pack()/unpack() support for signed
 integers with specific endianness
To: internals@lists.php.net
References: <CAMU7irLuV_CWR37odtuu0TL7io_bONy+5xebY82YnVb38RtEzg@mail.gmail.com>
 <CAMU7irLP0LHZzzkgXywBjp_Gp1_2rHY-erg85y4ahStOoWZZTQ@mail.gmail.com>
 <86c27cd68c8ba8056d832a845eb15dcd@bastelstu.be>
 <nTMJmPptsOwV9oUvFHMVGdhRXwVQfulxm5r8se3cReGLgjL4OZO48hzZmytxUnDvMto_2EpQGB42dUOR4a3IwjjNRxAwFOJkxsEQne1vW3s=@gpb.moe>
 <aa3727123e6a47421d39afc8bb11ff2f@bastelstu.be>
 <4ecce462-6d20-4958-931d-b160e79752c4@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <4ecce462-6d20-4958-931d-b160e79752c4@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: dossche.niels@gmail.com (Niels Dossche)

On 03/11/2025 18:33, Rob Landers wrote:
> 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.

AFAIU the old way of doing things won't break with Tim's suggestion. So there's no need to switch strings.
It just adds the possibility of using <>.
I agree it's already tricky enough to get things right, which is _exactly_ why Tim's approach is the right one. Instead of adding more arbitrarily chosen letters we now have a more meaningful way to indicate endianness. It also is proven by Tim's patch that this isn't hard to achieve. While implementation-wise adding some more letters is easier, Tim's patch isn't really difficult anyway.
I will vote against the RFC in its current form in favor of Tim's approach.

Kind regards
Niels