lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Am Di., 15. Nov. 2022 um 09:07 Uhr schrieb Viacheslav Usov <>:
> The catch here is that this is only correct when your function is
> called as a  "C function" from Lua. If it was called by another
> function of yours, then the Lua stack will be preserved and the caller
> will have to deal with it. It may be (badly) surprised by the extra
> data on the stack.

Well, this "daisy chain function" com_print_i is very well documented
in my code, and it is very clear that this function expects 3 further
optional parameters on Lua stack position 1, 2, 3... .

... yes of course, if I also invoke "com_print_i" from other positions
inside my C code (I do this), then of course this must be carefully
checked... .

... But if I call ANY function to which I pass lua_State* L on start,
I would always be very careful to pass the correct Lua stack
parameters, this is clear to me... .
> Another thing you should pay attention to is that Lua guarantees, when
> calling a C function, that the stack will have LUA_MINSTACK slots. The
> C function (and whatever it calls) is responsible for calling
> lua_checkstack() if more stack space is required.

Thank you for lua_checkstack hint, but yes, this "lua_checkstack" I
fortunately also meanwhile invoke very often... . (just NOT because of
3 new stack items, but as soon as I start pushing possibly more than
3-5 return values on the stack, I check this... mainly in Lua
functions similar to string.byte which can give back MANY return