On 14/10/2014 19:53, Lester Caine wrote:
On 14/10/14 19:33, Andrea Faulds wrote:
On 14 Oct 2014, at 19:29, Lester Caine <
[email protected]> wrote:
If a 64bit build of PHP is using a simple integer key for a BIGINT key
from the database, what will be the equivalent on a 32bit build?
It may be that we have to add code to the DB drivers to ensure that
BIGINT remains a standard string conversion on both platforms in order
to maintain consistent results. One being a simple integer key and the
other a GMP based key IS a problem when the key is constructed from
other shifted elements. This may be no more complicated than happens
now, but is a real life situation that needs a consistent result.
So, we’re talking about array keys, right? Well, strings sometimes become integer keys, and sometimes become string keys in arrays. This is actually the same behaviour the RFC and patch currently have for bigints: if it’s in the range of a long, it’s an integer key, otherwise a string key.
So the handling would actually be the same as now for array keys.
The real life situation is that databases have used a 64bit integer as
the primary key for records in a table for a long time now. Loading
these records into arrays using the primary key as the array key is a
natural process but as you have identified currently once they go over a
32 bit value they switch from simple integer to strings. Upgrading PHP
to natively support 64bit integers on 64bit platforms but leaving them
as 32bit on 32bit platforms is creating an inconsistency which this rfc
seems to be making more complex rather than less. This why I was simply
looking for a 64bit integer type that works as a simple integer on 32bit
platforms as well. GMP is overkill for this simple case and only needed
when one actually needs integers bigger than 64bit, and normal
programming does not need that in PHP7, just a clean 64bit integer.
Currently we can do any necessary 64bit maths on the keys in the
database, but for cross database working a consistent solution inside
PHP would help.