Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocE8gZyTfc4uaJdC+ccyK0qNFgPaS82G99=PdCyrMn6Amg@mail.gmail.com>
References: <CAPwsocHegEcF7kQEgwjC=PbkJKq7aq8Bv_A6QAy2fPFghJ=0WQ@mail.gmail.com>
	<CAPwsocE8gZyTfc4uaJdC+ccyK0qNFgPaS82G99=PdCyrMn6Amg@mail.gmail.com>
Date: Fri, 12 Sep 2014 15:36:30 +0200
Message-ID: <CAEZPtU7Q78F89Sxz_M=EJTTxmB+onJNxRkRhSLi3+gKNYd9UaQ@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c21eda7f10ed0502de5f75
Subject: Re: [PHP-DEV] Re: pack() and unpack() 64 bit format codes
From: pierre.php@gmail.com (Pierre Joye)

--001a11c21eda7f10ed0502de5f75
Content-Type: text/plain; charset=UTF-8

On Sep 12, 2014 2:10 PM, "Leigh" <leight@gmail.com> wrote:
>
> 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?

I would suggest to create a rfc as I am pretty sure many miss this thread
(like me). It can the be used to document the new features if accepted.

--001a11c21eda7f10ed0502de5f75--