[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Numeric key collision related bug in Lua 5.3
- From: Andrew Starks <andrew.starks@...>
- Date: Tue, 21 Apr 2015 15:36:16 -0500
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 <firstname.lastname@example.org> 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(tostring(a), tostring(b))
> print(tostring(a) == tostring(b))
How could (or "Why should") Lua be made to treat a and be as two separate keys?