Re: Table behavior in Lua 5.4

[Andrew Gierth <andrew@...>]

>>>>> "William" == William Ferguson <wpferguson@gmail.com> writes:

 William> If I populate a table then read it back like this
 William>   lua_newtable(L);
 William>   lua_pushstring(L, "this is a test");
 William>   luaL_ref(L, -2);

Note that luaL_ref could add the value at any integer index, it's
basically a chance implementation detail that it uses index 1 here. (The
normal use of luaL_ref is with the registry as the table, in which case
the index would probably be 4 or so.)

Also, luaL_ref can and will make other modifications to the specified
table besides adding an entry for the provided value; the only guarantee
is that it'll only use integer keys and won't do anything that's not
safe to do to the registry itself. If you use luaL_ref with a table you
provide yourself, you shouldn't be using the integer keys of that table
for anything else.

The current implementation of luaL_ref uses a specific integer index as
the head of a freelist; the index for this is chosen not to conflict
with the fixed entries in the registry.

 [...]

 William> I get the following output

 William> lua table has length 1.000000
 William> 1.000000 - string
 William> 3.000000 - number

 William> In Lua 5.3 I get

 William> lua table has length 1.000000
 William> 1.000000 - string

 William> Is this a bug, or am I missing something?

Why would it be a bug?

The difference in behavior is down to the fact that 5.4's luaL_ref
creates the freelist immediately on first use, whereas 5.3 creates it on
the first luaL_unref. The freelist ends up at index 3 so as not to
conflict with predefined registry entries, and then the new reference is
arbitrarily being assigned index 1, so the table is not a sequence.

lua_len on the 5.4 version could return either 1 or 3, entirely
arbitrarily (it's defined as returning the position of _any_ frontier in
the table, not necessarily the first one).

-- 
Andrew.