64 bit format codes for pack() and unpack()
- Version: 1.0
- Date: 2014-09-12
- Author: email@example.com
- Status: Implemented
- First Published at: https://wiki.php.net/rfc/pack_unpack_64bit_formats
The purpose of this RFC is:
- Adding Perl-compatible format codes for native-endian integer conversion.
- Introducing Perl-incompatible format codes for endian specific integer conversion.
Pack and unpack are functions inspired by Perl which uses the format codes “q” and “Q” to represent native-endian signed and unsigned 64 bit integers.
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 that can be used to specify endianness however for consistency with PHPs current 32 bit format codes it would be a good idea to introduce codes for these as well.
The letters “J” and “P” have been selected because they already exist in Perl but their function does translate to PHP.
J is for Perl internal integer values and P is for a pointer to a structure. Both of these are things that make no sense in PHP.
J - unsigned long long (always 64 bit, big endian byte order) P - unsigned long long (always 64 bit, little endian byte order)
They are ordered such that J < P in the same way that N < V to make it intuitive for developers to remember what the codes mean.
No codes have been planned for endian specific signed values as PHP does not currently have these for 32 bit systems. The “i” and “I” codes exist, but these are documented as platform-dependant sized integers.
On 32 bit builds (with the current patch) these format codes are unavailable and will result in the same warning as usual for invalid format codes.
Backward Incompatible Changes
Proposed PHP Version(s)
All SAPIs are affected equally, gaining access to the new format codes.
To Existing Extensions
No impact - the only change is to the format string which can be cached the same as before.
Nothing brought up during discussion phase
Unaffected PHP Functionality
The change is constrained to (un)pack, there is not a lot of scope for this to affect any existing functionality, and tests indicate that nothing is measurably broken/
50%+1 majority as no core language changes are being made.
Voting begins: 2014-09-26
Voting ends: 2014-10-03
Patches and Tests
I consider this patch final unless issues with the implementation are raised.