Re: Numeric key collision related bug in Lua 5.3

[Andrew Starks <andrew.starks@...>]

On Tue, Apr 21, 2015 at 3:29 PM, Ross Berteig <Ross@cheshireeng.com> wrote:
>
> On 4/21/2015 1:04 PM, Andrew Starks wrote:
>>
>> On Tue, Apr 21, 2015 at 2:45 PM, Tim Hill <drtimhill@gmail.com> wrote:
>>>
>>> ....
>>> The reality is Lua has three number ranges:
>>> [a] Integers with a magnitude less than 2^52 (and can be represented
>
>>> exactly either as float or integer)
>>>
>>> [b] Integers with magnitude greater than 2^52 but less than 2^63
>>> (and canonly be represented exactly as integers)
>>> [c] Floats with magnitudes greater than 2^63
>>>
>>> It's the [b] range that is the problem here, and I don't see any
>>> clear guidelines in the Lua docs to indicate how this range is
>>> handled whenused as table keys.
>>> ....
>>
>> .... what are the substantive consequences beyond that?
>>
>> It would add tremendously to my understanding if someone someone would
>> make up a story that includes a user in a real-world scenario hitting
>> this edge case. Is there a story that could be imagined that includes
>> how this may be exploited by a nefarious user?
>
>
> One of the only reasons I've personally used floats for table keys has
> been for memoization, where a table is used to cache results of (a
> presumably expensive) calculation. Having different input values return
> the same cache slot would be wrong, and likely very hard to debug.
>
> IMHO, I would think that integers should only get floated implicitly (or
> vice-versa) when that conversion can survive a round trip. Then whether
> the key is "really" the integer or the float is purely an implementation
> detail. Having a range of values which plainly compare different and
> which are treated as the same key seems to violate the principle of
> least surprise.
>
> --
> Ross Berteig                               Ross@CheshireEng.com
> Cheshire Engineering Corp.           http://www.CheshireEng.com/
>
>

Floats have  precision ceiling and floor. It's something that I have
spent a bit of time being frustrated over, as well (in a context that
is not related to table keys) and I think that it's established that
the issues are not related to Lua, specifically.

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