On Tue, May 20, 2014 at 11:12 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> On Wed, May 21, 2014 at 5:45 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> This is the reason why DB data values and Web inputs should not be
>> converted to native PHP data type blindly :)
>> It could work, but it cannot work with 64bit int.
>>
>
> It may be changed not to use int key (use string key) when int key
> overflows,
> then it would work.
>
> However, many users are trying to use strict type. Users may experience
> data validation errors for large int with 32bit int key. It would be
> better to allow
> 64bit int if int is 64bit. I prefer consistency, so array int key is
> better to support
> 64bit int key. IMHO.
>
> Similar argument applies to string also. It would be WTF, when users try to
> access string offset over 32bit values. Data dealt with PHP is getting
> larger
> and larger. It would be an issue sooner or later.
>
As I have already said: 64bit (or rather 63bit) integer keys are already
supported on LP64 and ILP64 platforms. This proposal supports them on LLP64
as well. The issue you're hitting has nothing to do with 64bit integers -
you are using a key that is *way* larger than that, i.e. a double key.
Double keys are handled by converting them to integers frist. This
conversion is a wraparound conversion, not a clamp conversion, so you end
up with some meaningless negative number.
If you want to change the handling of double keys, that is - as far as I
can see - an entirely different proposal, that's only tangentially related
to 64bit support.
Nikita