Re: Lua C Functions

Dear William,

That's actually a good point. I was thinking I might do `lua_settop(L, 0)` to avoid stack overflows since I don't quite have to deal with coroutines just yet... BUT! I do want to support a generic way to do that in the future from the library.

The reason this came up for me was because I was using some magic to basically count the number of arguments in a C function and then auto-wrap it. Problem is, certain types can be "left out" (e.g., a pointer is automatically left out and becomes nil/nullptr), and while the getters for lua types using "lua_to{x}" worked just fine with some type checking, the magic stuff would still try to pop exactly N arguments, even if only a few were left on the stack. I guess I could just do a `min(arg_count, lua_gettop(L))` so I don't over-pop the stack, and so I can handle the case of coroutines nicely too?

Just ideas, really.

Sincerely,

ThePhD

On Mon, Jul 11, 2016 at 3:35 PM, William Ahern <william@25thandclement.com> wrote:

On Sat, Jul 09, 2016 at 12:29:25PM -0400, ThePhD wrote:
> Dear Alysson,
>
> Thank you for the clarification! I was unsure, since almost every
> example I had seen did this and it was not really specified anywhere
> exactly. My fear was that if the function called it might "leave" the
> arguments on the stack below where the results were, and eventually trash
> the VM with overflows. I'm glad this is not the case, and this will allow
> me to improve my code.

When you return from a function Lua will clean up the stack, capturing the
top N values on the stack according to the return value and discarding the
remainder, if any.

However, where you can run into trouble is repeatedly calling from the same
call frame context lua_call, lua_resume (whether or not from the same C
function invocation), and similar routines. You _can_ easily overflow the
stack if, for example, you don't the pop return values from prior calls.

This happened to me when I first began using Lua. I was issuing callbacks on
a coroutine and not managing the stack correctly. After too many callbacks
I'd overflow the stack. But it didn't always happen and it was a headache to
track down as I didn't have a strong grasp on Lua's stack semantics. It was
made more complex case because some callbacks would often yield to be
resumed by an event loop, so the stack management code was split across
multiple different C functions.

This is the exception to the rule. When you `return lua_yield(L, N)` from
your C routine, either directly or indirectly from another function
invocation, then Lua will preserve the stack and only pop the number of
values (N) you want to yield. This is by design because the stack is
normally where you keep your state for when the coroutine is resumed. That's
in contrast to, e.g., a simple closure used as an iterator, where you keep
your state in upvalues. (Neither strategy is mutually exclusive--a closure
invocation can be yielded and resumed like any other function, and also make
use of its upvalues before and after resumption.)

My quick fix back then was to do `lua_settop(L, 0)` before each callback.
Since then I prefer to add an assert that verifies my stack discipline code
is working correctly.