Re: pack() and unpack() 64 bit format codes
| From: | Leigh | Date: | Fri, 12 Sep 2014 12:09:55 +0000 |
| Subject: | Re: pack() and unpack() 64 bit format codes | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77160@lists.php.net to get a copy of this message | ||
On Sep 9, 2014 7:36 PM, "Leigh" <leight@gmail.com> wrote:
>
> Hi Internals,
>
> I would like to propose giving pack() and unpack() 64 bit format
> codes, mimicking the current behaviour of 32 bit format codes.
>
> Pack and unpack are obviously functions inspired by Perl, which has
> the 64 bit format codes 'q' and 'Q'. So the first half of my proposal
> is to give pack() and unpack() these options.
>
> q - signed long long (always 64 bit, machine byte order)
> Q - unsigned long long (always 64 bit, machine byte order)
>
> Perl does not have format codes to specify endianness, so the second
> half of my proposal is to introduce two more format codes for PHP that
> behave differently from Perl.
>
> J - unsigned long long (always 64 bit, big endian byte order)
> P - unsigned long long (always 64 bit, little endian byte order)
>
> I have chosen these letters _because_ they already exist in Perl,
> however their function does not suit PHP. J is for Perl internal
> integers, and P is for a pointer to a structure. Both of these are
> things that make no sense to support in PHP.
>
> I have ordered them so that J < P in the same way that N < V,
> hopefully making it a bit more intuitive for developers to remember
> what the codes mean (also P rhymes with V.. kinda)
>
> I don't think this requires an RFC, as it does not break any existing
> expected behaviour.
>
> I'd like to hear the lists opinion on introducing these new formatting
options.
>
> Provisional PR: https://github.com/php/php-src/pull/812
>
> Cheers,
>
> Leigh.
So, no objections?