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.
Hi Internals,
I would like to propose giving
pack()andunpack()64 bit format
codes, mimicking the current behaviour of 32 bit format codes.
What would this do on 32-bit platforms?
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 givepack()andunpack()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.
Why is there no big/little-endian signed long long?
--
Andrea Faulds
http://ajf.me/
Why is there no big/little-endian signed long long?
Because there is no big/little-endian signed long :)
Why is there no big/little-endian signed long long?
I suppose you could argue that these count
i - signed integer (machine dependent size and byte order)
I - unsigned integer (machine dependent size and byte order)
However they specify machine dependent size, and they do not increase
to 64 bit on the average 64 bit system (sizeof(int) remains at 4 when
sizeof(long) goes to 8 on my systems). It's obviously possible to add
signed variants, so I open the floor to the usual bikeshedding on what
letters should be used, but I'd prefer to stick to translating the
32bit specific behaviour to 64 bit for now, such was the goal of the
PR.
Hi Internals,
I would like to propose giving
pack()andunpack()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 givepack()andunpack()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?
Hi Internals,
I would like to propose giving
pack()andunpack()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 givepack()andunpack()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.