Re: Numeric key collision related bug in Lua 5.3

[Ross Berteig <Ross@...>]

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/