Re: Possible bug relating to table sizes
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Possible bug relating to table sizes
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: 2011年10月31日 09:29:17 +0100
On 29/10/2011 12.07, Andrew Scott wrote:
I was working on some code that involved copying indexed tables, and
noticed that copying an indexed table T1 that was missing a [1] key (so
that #T1 == 0) yielded a table T2 that would return the length as if the
[1] key were in T2. Below is the simplest code that I could get to
reproduce this. Removing any of the keys 2, 3, or 4 from T1 makes both
tables return a size of 0, but adding additional keys after 4 to T1
simply causes T2 to reflect the new highest key.
[...]
I don’t know why any of this is happening, but it seems extremely buggy
to me. Why are my tables that are missing a [1] key returning a size?
ipairs() will not traverse them, but (for i=1, #table) will? This should
not be.
The length operator '#' returns the intuitively-correct value only for
tables which are "arrays" ("sequences", in the new Lua 5.2 parlance),
i.e. tables whose numeric keys begins at 1 and ends at some other
integer N. If there are "holes" or non integer numeric keys, '#' returns
weird values, although its behaviour is well-defined in the manual [1]
(this behaviour was criticized and lead Lua Team to remove the
definition of '#' for non-sequences in 5.2 and clarify the concept of
"array", now formally called "sequences" in the manual [2]).
The same applies to ipairs (it will traverse an array only if *it is* an
"array") and almost all other table library functions.
[1] http://www.lua.org/manual/5.1/manual.html#2.5.5
[2] http://www.lua.org/work/doc/manual.html#3.4.6