Re: Numeric key collision related bug in Lua 5.3

[Coda Highland <chighland@...>]

On Tue, Apr 21, 2015 at 1:55 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> On Tue, Apr 21, 2015 at 3:46 PM, Coda Highland <chighland@gmail.com> wrote:
>> nkey = (1<<63)-333
>> fkey = nkey + 0.0
>> print(fkey == nkey)             -> true
>>
>> t = {}
>> t[nkey] = "nkey"
>> t[fkey] = "fkey"
>> print(t[nkey], t[fkey]) -> "fkey" "fkey"                -- Expected
>> based on equality check above
>>
>> t[0] = 0
>> print(t[nkey], t[fkey]) -> "fkey" nil           -- Unexpected
>
> Thank you for your patience. What am I doing wrong here? I only get
> expected behavior:
>
>> nkey = (1<<63) - 333
>> fkey = nkey + 0.0
>> print(fkey == nkey)
> true
>> t = {[nkey] = 'nkey', [fkey] = 'fkey'}
>> print(t[nkey], t[fkey])
> nkey    fkey
>> t[0] = 0
>> print(t[nkey], t[fkey])
> nkey    fkey
>> t[nkey] = 'nkey'
>> t[fkey] = 'fkey'
>> print(t[nkey], t[fkey])
> nkey    fkey
>> t[0] = 0
>> print(t[nkey], t[fkey])
> nkey    fkey
>
> Andrew
>

You're getting different behavior because this misbehavior is
sensitive to the specific construction of the table. What you've
demonstrated here is that using the table constructor can result in a
different internal representation than using serial assignment -- a
fact that is already well-known, from many discussions regarding the
behavior of "array part" versus "hash part".

If you had reinitialized t to {} before the t[nkey] = 'nkey' line, you
would be more likely to see the behavior under discussion.

It may make a difference, too, if you used t = { [fkey] = 'fkey',
[nkey] = 'nkey' } as opposed to the ordering you have now.

/s/ Adam