Thank you for your detailed explanation.
> https://github.com/lua/lua/blob/6e1aec7a677a9891f2f8ca57e039d9984fdc69bc/lvm.c#L1085
Strange as it is, this is correct. See previous comment:
/* invalidate top for instructions not expecting it */
lua_assert(isIT(i) || (L->top = base));
The idea is that only opcodes marked with 'isIT' should use L->top.
To test this, all other opcodes set L->top to an "absurd" value
(base, so that it is out of the range of valid registers) to force
some error if it is used.
You should then mark it in the code explictly as:
/* invalidate top for instructions not expecting it */
lua_assert(isIT(i) || (L->top = base) != 0);
This makes clear you want an assignment of top with "absurd" base, and then the zero-test of this "absurd" base ; it and will shut up linters (The C compiler already performs implicitly
the "!= 0" test on all non-boolean operands of "||"; but when you use an assignment as an operand of "||" instead of a boolean comparison, lot of compilers have a linter emitting a warning for the frequent possible typo or misuse of "=" instead of "=="; such typo/misuse does not occur in Lua programs because assignments cannot be subexpressions, and in Lua you would have used an if/else to separate the side-effect for the assignment).
However I wonder if the side-effect of this conditional assignment, expected when compiling in debug mode where lua_assert() will perform it, should not be made when the
lua_assert() macro is a do-nothing in non-debug mode (and then does not compile its _expression_ given in parameter):
/* invalidate top for instructions not expecting it */
if (!isIT(i)) {
L->top = base;
lua_assert(base != 0);
}
For me the linting warnings emitted by C compilers are correct, meaning that you need to fix it because of the conditional side-effect of the assignment.
