Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77160
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocHegEcF7kQEgwjC=PbkJKq7aq8Bv_A6QAy2fPFghJ=0WQ@mail.gmail.com>
References: <CAPwsocHegEcF7kQEgwjC=PbkJKq7aq8Bv_A6QAy2fPFghJ=0WQ@mail.gmail.com>
Date: Fri, 12 Sep 2014 13:09:55 +0100
Message-ID: <CAPwsocE8gZyTfc4uaJdC+ccyK0qNFgPaS82G99=PdCyrMn6Amg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7bd6b9acc55b840502dd29b1
Subject: Re: pack() and unpack() 64 bit format codes
From: leight@gmail.com (Leigh)

--047d7bd6b9acc55b840502dd29b1
Content-Type: text/plain; charset=UTF-8

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?

--047d7bd6b9acc55b840502dd29b1--