Re: Numeric key collision related bug in Lua 5.3

[Franz Fellner <alpine.art.de@...>]

Ross Berteig 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.

IMHO even here using floats as keys is not a good idea:
> x=1.1*1.1
> y=1.21
> print(x)
1.21
> print(y)                                                                                                                                                                              
1.21
> print(x==y)
false

But probably it is OK for your use case. (And I know this isn't related to this whole thread).

> 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/
> 
>