The parameter 'nresults' in 'lua_call' and similar functions has a
limit of 250. It already had an undocumented (and unchecked) limit of
SHRT_MAX, but it is seldom larger than 2.
Undoing previous commit. Returning TValue increases code size without
any visible gains. Returning the tag is a little simpler than returning
a special code (HOK/HNOTFOUND) and the tag is useful by itself in
some cases.
Instead of receiving a parameter telling them where to put the result
of the query, these functions return the TValue directly. (That is,
they return a structure.)
Avoid silent conversions from int to unsigned int when calling
'luaH_resize'; avoid silent conversions from lua_Integer to int in
'table.create'; MAXASIZE corrected for the new implementation of arrays;
'luaH_resize' checks explicitly whether new size respects MAXASIZE.
(Even constructors were bypassing that check.)
'lua_rawgeti' now uses "fast track"; 'lua_rawseti' still calls
'luaH_setint', but the latter was recoded to avoid extra overhead
when writing to the array part after 'alimit'.
The meaning of different GC parameters changed, so there is point in
supporting old values for them. The new code simply ignores the
parameters when changing the GC mode, so the incompatibility is small.
The generational mode also uses the parameters for the incremental
mode in its major collections, so it should be easy to change those
parameters without having to change the GC mode.
The array part of a table wastes too much space, due to padding.
To avoid that, we need to store values in the array as something
different from a TValue. Therefore, the API for table access
should not assume that any value in a table lives in a *TValue.
This commit is the first step to remove that assumption: functions
luaH_get*, instead of returning a *TValue where the value lives,
receive a *TValue where to put the value being accessed.
(We still have to change the luaH_set* functions.)
'luaD_growstack' already checks that. This commit also fixes an
internal bug in 'luaD_growstack': a large 'n' could cause an arithmetic
overflow when computing 'needed'.
The existence of 'lua_closeslot' is no reason for lua_pop not to close
to-be-closed variables too. It is too error-prone for lua_pop not to
close tbc variables being popped from the stack.
To-be-closed variables are linked in their own list, embedded into the
stack elements. (Due to alignment, this information does not change
the size of the stack elements in most architectures.) This new list
does not produce garbage and avoids memory errors when creating tbc
variables.
