Re: Are two arguments always passed to the Unary Minus metamethod?

Thanks.

I missed that note since I spent most of my time in the Lua 5.1 manual (Luajit & Lua 5.1 is main target)
The explanation of the added "dummy" parameter is in both 5.2 and 5.3 manuals so it's expected behaviour.

On Mon, Oct 31, 2016 at 5:25 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

2016-10-31 4:58 GMT+02:00 dl acc <nydlacc123@gmail.com>:

> I'm hoping for a bit of confirmation that my understanding of how Lua passes
> arguments to __unm is correct. I have a library that dispatches to the
> correct C++ function depending on the contents of the Lua stack. It checks
> that the number and type of the Lua data on the stack is appropriate for the
> C++ function being called.
>
> Everything was working until I got an unexpected failure after setting a C++
> function to be called as the unary minus operation of a userdata. The Lua
> documentation says that the __unm handler is called as handler(operand) so I
> wrote the C++ function to take one argument and therefore one value should
> be on the Lua stack when it is invoked as a lua_CFunction. However, two
> values were on the stack instead and so my library refused to call the
> one-argument C++ function in that case.
>
> I rebuilt with both Luajit and Lua 5.3 and got the same behavior so I did a
> bit of digging and found this in lapi.c
>
> LUA_API void lua_arith (lua_State *L, int op) {
> lua_lock(L);
> if (op != LUA_OPUNM && op != LUA_OPBNOT)
> api_checknelems(L, 2); /* all other operations expect two operands */
> else { /* for unary operations, add fake 2nd operand */
> api_checknelems(L, 1);
> setobjs2s(L, L->top, L->top - 1);
> api_incr_top(L);
> }
> /* first operand at top - 2, second at top - 1; result go to top - 2 */
> luaO_arith(L, op, L->top - 2, L->top - 1, L->top - 2);
> L->top--; /* remove second operand */
> lua_unlock(L);
> }
>
> It seems that the addition of the "fake" operand is reason for the
> unexpected extra value on the stack. Is my understanding correct? I can
> accomodate this by rewriting my C++ __unm handler to take two arguments
> instead and ignore the second one. Of course, it will break if this Lua
> implementation detail changes in the future. Alternatively my library could
> stop requiring an exact match for the number of parameters, instead allowing
> the call if at least as many Lua values as there are C++ parameters is on
> the stack. I don't really want to do that though, because the library allows
> overloading so not requiring an exact match of parameter counts and Lua
> stack size complicates the set of applicable functions.

"For the unary operators (negation, length, and bitwise not), the metamethod
is computed and called with a dummy second operand, equal to the first one.
This extra operand is only to simplify Lua's internals (by making
these operators
behave like a binary operation) and may be removed in future versions.
(For most uses this extra operand is irrelevant.)" -- Lua 5.3 User's Manual