Instead of an explicit value (field 'b'), true and false use different
tag variants. This avoids reading an extra field and results in more
direct code. (Most code that uses booleans needs to distinguish between
true and false anyway.)
ISO C states that standard library functions should not be called
with NULL arguments, unless stated otherwise. 'sprintf' does not
state otherwise, and it doesn't hurt to be on the safe side.
Several "metamethods" are not required to be methods (functions),
so it seems clearer not to call them metamethods. The manual now
uses the word 'metavalue' for those values.
The file 'bugs' reports bugs in several different versions
(corresponding to different branches in the repository), without
a clear division of "this bugs belongs to this version". So, it
doesn't make sense to track it along with one (or many) versions.
The initial "\n\t" to properly indent a searcher message is being added
by 'findloader' when building the error message, instead of being
included in the original message by each searcher itself.
In 'str__dump', the call to 'lua_dump' assumes the function is on the
top of the stack, but the manual allows 'luaL_buffinit' to push stuff
on the stack (although the current implementation does not). So, the
call to 'luaL_buffinit' must come after the call to 'lua_dump'.
The old definition did one test for nil, but three tests for the all
too common booleans (and two tests for other values); this definition
does two tests for all values.
New threads were being created with very small C-stack limits.
This is not a problem for coroutines, because 'lua_resume' sets
a new limit, but not all threads are coroutines.
The performance of the Lua compiler is not critical for Lua
performance, but it is a big component in the source. So, it makes
sense to trade speed for size in this component.
- Several details in 'lcode.c'
- A few more tests for code generation
- Bug in assert in 'lcode.c' ("=" x "==")
- Comments in 'lopcodes.h' and 'ltable.c'
The difference in performance between immediate operands and K operands
does not seem to justify all those extra opcodes. We only keep OP_ADDI,
due to its ubiquity and because the difference is a little more relevant.
(Later, OP_SUBI will be implemented by OP_ADDI, negating the constant.)
