Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129412 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id CF9911A00C9 for ; Sun, 23 Nov 2025 17:00:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763917261; bh=ELJqP+lBJQu4fBt/MRZmOPUnfBpl8/KoI3MiPQwfAKs=; h=Date:Subject:To:References:From:In-Reply-To:From; b=X6r+6e7j2fM3kQ6+H2XUZQYhhSG25Q5c5D4UPhzxoUkby/lZEcfN5PdChZEnz58SC HDJNRLD0czmyQQ3KbHgkQ9AFt2GKX5Zasst6b7FCscwyL52GmSuBOj4kj8bVJ/QOgt 0qmNXJwW0vu0Zt2hwZOjUdJ4SZlPjaTTVvfSLfQPgG5Y2wlI2namPMC6qJ/VT8lNI9 C1MKJBCME51wfFMehDO/tohjmpUf7bFALxd2NQtEaTCniPCdCW11Vgt/AOuVCODpZp 90OMrijWrq9OQMZUMi1UFBhB1vZppRgKaVTI65Tw/XGAmP+RaJZCj9LxAdoSKvuzH/ cCAVrLgGIXLWg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B9328180381 for ; Sun, 23 Nov 2025 17:00:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_20,DKIM_INVALID, DKIM_SIGNED,DMARC_PASS,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 23 Nov 2025 17:00:52 +0000 (UTC) Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4dDwFR5Qyyz9t5q for ; Sun, 23 Nov 2025 18:00:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mabe.berlin; s=MBO0001; t=1763917243; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JXYy6431IDL+gRb3GdJsXJ+NgENTa4z5DS7EmvIo6es=; b=aq161MPn80+vnsDPTQcqCCI51tuxSFVN99diMkjJjdAO6qmdPwAUaNboV3+Z/L80S06pDW q54g3kG+oLQQrFothhAXSW8Xj3BXHlFOo/m6MZvW7eDAzy7wj9NTsk2DXd4kZ8On7AtkYA Tr7ksg6j6pKx141Wsp7YLe0dpDOy3eOdda3vA/iNy2zRJCMsa8mDNaFiKC4Nh5TJK3SdW5 M0fHzrTCLZxK7JxXQx0oe6JHUEcyGBm5cORFjdJ9ODcdlthR4JUdNOF6WJeHWUIXOhtHm/ St8MKEcMZ39pqRH5KwE9RmMVGkeIYksXsAthMVxCtDn0bkXYsrCWDh4yQWP6pw== Content-Type: multipart/alternative; boundary="------------9sJQrgoMguOT03J26c2LmHFM" Message-ID: Date: Sun, 23 Nov 2025 18:00:42 +0100 Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 Subject: Re: [PHP-DEV] Re: [RFC] Add pack()/unpack() support for signed integers with specific endianness To: internals@lists.php.net References: <9b6665e9-7daa-4138-9e4d-180425cc7c8c@bastelstu.be> Content-Language: en-US In-Reply-To: <9b6665e9-7daa-4138-9e4d-180425cc7c8c@bastelstu.be> From: marc@mabe.berlin ("Marc B.") This is a multi-part message in MIME format. --------------9sJQrgoMguOT03J26c2LmHFM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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| . > * 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. > * 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 . 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. --------------9sJQrgoMguOT03J26c2LmHFM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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.
> * 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. 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.


--------------9sJQrgoMguOT03J26c2LmHFM--