[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: rename LUA_RIDX_CPCALL to LUA_RIDX_CCALL? (5.2.0-work2)
- From: Drake Wilson <drake@...>
- Date: Mon, 29 Mar 2010 08:32:13 -0500
Quoth Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br>, on 2010-03-29 08:57:21 -0300:
> > The dance required to get strings and boxed pointers passed to lua
> > callbacks is borderline ridiculous. :)
>
> What do you mean exactly?
I'm not the OP, but the problem as I see it is that you may have
C-level unwind requirements during data transfer from some other
source into Lua space.
E.g.:
char const *const str = some_library_get_string();
lua_pushstring(L, str); /* Memory leak if this fails! */
some_library_free_string(str);
and in this case you can't even easily use (5.1) lua_cpcall:
static int
actually_push_string(lua_State *L)
{
/* Wait a minute, there's no good way to get the string back
if the return values go away. */
lua_pushstring(L, (char const *)lua_touserdata(L, 1));
return 1;
}
so instead you have to do something like:
/* luaL_checkstack(L, 2, ""); */
lua_pushcfunction(L, &actually_push_string);
char const *const str = some_library_get_string();
lua_pushlightuserdata(L, str);
int const err = lua_pcall(L, 1, 1, 0);
some_library_free_string(str);
if (err != 0) lua_error(L);
There are sometimes ways to simplify this, but it's very tricky to
work with and get right every time.
(Incidentally, in a Lua bolt-on I'm currently working on privately,
I've bandied about the idea of providing C-level unwind-protect
registration of some kind for this exact reason, which might or might
not say anything about the topic.)
---> Drake Wilson