Instead of using variadics, hard-code array accesses for the
expected arity of door_operate_core, throwing away any
"future-proofing" that variadics were supposed to offer.
This is because in Lua 5.1, the length of arrays that contain
nil values anywhere in the sequence is apparently undefined, and
implementations are free to return the position of any value that
is followd by a nil, so length of {1, nil, 3} could be 1 or 3.
PUC lua seems to generally return 3, but LuaJIT takes more
liberties here (presumably exploiting UB for optimizations).
The problem arises when trying to unpack({1, nil, 3}) and LuaJIT
sees the length as 1 so return only <1>, instead of <1, nil, 3>.
This means that calling nodecore.door_operate(pos, ni, dir),
which was INTENDED for this API (it would look up node for you if
you didn't provide one) could result in the dir param being
lost due to packing the args into an array to defer them, and then
that array getting only partially unpacked.
Reference to WONTFIX bug where LuaJIT claims this is allowed UB:
https://github.com/LuaJIT/LuaJIT/issues/527
The solution for now is to stop relying on unpack (which is sort
of easy in its own way since I never really liked it). In the
specific case of nodecore.door_operate in particular, adding
more positional args (it already has 3) would be bad for other
reasons (should switch to a named passing style).
47f20ac2f0