Re: Numeric key collision related bug in Lua 5.3

[Coda Highland <chighland@...>]

On Tue, Apr 21, 2015 at 1:36 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> Is there an assertion that table keys represent a special case that
> deserves a guard in the implementation? The motivation for my question
> hopefully illustrated by a modification of Liam's example:
>
>> mi = math.maxinteger
>> a, b = mi +2.1, mi +3.5
>> print(a,b)
> 9.2233720368548e+018    9.2233720368548e+018
>> print(tostring(a), tostring(b))
> 9.2233720368548e+018    9.2233720368548e+018
>> print(tostring(a) == tostring(b))
> true
>
>
> How could (or "Why should") Lua be made to treat a and be as two separate keys?
>
> -- Andrew
>

This is a bit of a red herring.

Bringing the discussion back around to the actual issue: Remember that
what we're looking at is a case where they DO resolve as equal, yet DO
NOT yield the same table key.

Look back at Tim Hill's post earlier:

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

/s/ Adam