On Sep 12, 2014 2:10 PM, "Leigh" <lei...@gmail.com> wrote: > > On Sep 9, 2014 7:36 PM, "Leigh" <lei...@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.
