[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **Re: Numeric key collision related bug in Lua 5.3**
**From**: Tim Hill <drtimhill@...>
**Date**: Tue, 21 Apr 2015 12:29:28 -0700

> On Apr 21, 2015, at 12:20 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> Hmm this still looks like a bug to me. The entire hash/non-hash parts of tables are supposed to be purely implementation detail, yet here we are seeing the insertion of t[0] causing behavior changes to unrelated key(s). I’m not even sure what Lua is doing with that key, what does “float with integral value” mean for an integer that has no exact representation as a double-precision float (i.e. is > 2^52)?
>
> nkey = (1<<63)-333
> fkey = nkey + 0.0
> print(fkey == nkey) -> true
>
> t = {}
> t[nkey] = “nkey”
> t[fkey] = “fkey”
> print(t[nkey], t[fkey]) -> “fkey” “fkey” — Expected based on equality check above
>
> t[0] = 0
> print(t[nkey], t[fkey]) -> “fkey” nil — Unexpected
>
> —Tim
>
Contrast with this…
t = {}
t[fkey] = “fkey”
t[nkey] = “nkey”
print(t[nkey], t[fkey]) -> “nkey” “fkey” — Notice difference from previous example
t[0] = 0
print(t[nkey], t[fkey]) -> “nkey” “fkey” — Notice difference from previous example
This looks like a bug in how keys are checked for integral values, and isn’t related (so far as I can see) to the way Lua handles equality between values of different types.
—Tim