Re: localized errors for allocating new objects

[Drake Wilson <drake@...>]

Quoth Roberto Ierusalimschy <roberto@inf.puc-rio.br>, on 2010-03-29 13:05:56 -0300:
> > Anyway, I hadn't looked at the latest 5.2 when I wrote that.  If
> > luaL_cpcall acts like lua_cpcall but with return values, then it would
> > be marginally easier, but you'd still have that extra C function,
> > which is a large part of the pain of that solution.
> 
> Well, that is the general philosophy of Lua. Usually it does not provide
> functions that you can write yourself with a few lines of code, unless
> it is frequently needed.

(Rumination follows.)

Yar.  The boundary is kind of fuzzy, of course.  Boxing values from
external C code as strings or userdata seems to be a common case where
you have a C unwind constraint in effect for deallocation and a single
primary Lua allocation operation that may fail.

Actually, it may be that strings are mildly special here: userdata can
often be preallocated and then filled in later, but there is no such
mechanism for strings, so when boxing strings from C you're almost
guaranteed to have the above conflict.  Similarly, other types (table,
closure, thread) either can either usually be precreated or would only
appear afterwards once the C unwind constraint is gone, so once you've
gotten the string data into Lua space you're safe.

In the case of userdata you also have __gc metamethods available and
frequently in use, in which case once you've gotten the pointer (or
whatever it is) into Lua space you're safe, since afterwards an
unexpected Lua unwind won't destroy the finalizer.  (A second approach
to pulling strings in would be to use a temporary finalized userdata,
in fact, but that's even more cumbersome.)

> This function was not in the work2 manual. Its entry is like this:
> 
>   int luaL_cpcall (lua_State *L, lua_CFunction f, int nargs, int nresults);
> 
>   Calls a C function in protected mode.
> 
>   This function is equivalent to lua_pcall, but it calls the C function
>   f (instead of a Lua function in the stack) and it does not have an
>   error handler function.

That looks good to me.  Is this from a new 5.2-workN version that's
been released that I missed, or has it only been internal?

> -- Roberto

   ---> Drake Wilson