Re: Numeric key collision related bug in Lua 5.3

[Coda Highland <chighland@...>]

On Wed, Apr 22, 2015 at 9:13 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> An interesting bug has been found in Lua 5.3
>>
>> t = {[(1<<63)-333] = 0}
>> key = next(t) + 0.0
>> t[key] = "Lua is great!"
>> print(t[key])          --> Lua is great!
>> t[0] = "Are you sure?"
>> print(t[key])          --> nil
>>
>> Why Lua is not great anymore?
>
> The problem is the current definition of equality. The way it is
> defined (compare integer-float converting the integer to float) makes
> it non transitive:
>
>> t1 = (1<< 62) + 1
>> t2 = t1 + 2
>> t3 = t1 + 0.0    -- will be rounded to 2^62
>> print(t1 == t3, t2 == t3, t1 == t2)
>    --> true     true    false
>
> That is all good, until you try to put these values as indices
> in a table. Because there is no transitivity, there is no
> partition. Dependening on the order that these elements are compared
> to each other, they will collide (or not) in different ways.
>
> My guess is that the best sollution would be to change the definition
> of equality (to a simpler one :-). Two numbers should be considered
> equal if they represent the same mathematic value; period. (In terms
> of implementation, it means that integer-float should be compared
> converting the float to an integer; if the conversion fails, the numbers
> cannot be equal.) That definition is simple, sounds sensible and
> easy to explain, and makes equality transitive.
>
> -- Roberto
>

This sounds good to me. Very reasonable.

/s/ Adam