This is an old revision of the document!
64 bit format codes for pack() and unpack()
- Version: 0.1
- Date: 2014-09-12 (use today's date here)
- Author: Leigh, leight+php -> gmail
- Status: Under Discussion
- First Published at: https://wiki.php.net/rfc/pack_unpack_64bit_formats
Introduction
pack() and unpack() do not currently support format codes for converting data to and from 64 bit integers.
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.
Proposal
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 unsigned 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
None.
Proposed PHP Version(s)
PHP 5.6
RFC Impact
To SAPIs
No impact
To Existing Extensions
No impact
To Opcache
No impact - the only change is to the format string which can be cached the same as before.
New Constants
None
php.ini Defaults
Nothing new
Open Issues
Nothing yet
Unaffected PHP Functionality
Everything else
Future Scope
Maybe revisit when we have 128bit words.
Proposed Voting Choices
50%+1 majority as no core language changes are being made.
Patches and Tests
I consider this patch final unless issues with the implementation are raised.
Implementation
TODO
References
Rejected Features
TODO