>>>>> "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.
Thank you everyone for making me a little more knowledgeable than I was yesterday
Bill
