Re: localized errors for allocating new objects

[Roberto Ierusalimschy <roberto@...>]

> 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. Were Lua to provide a protected pushstring,
it should provide protected versions of many other functions, such as
newtable, newuserdata, settable, etc. Most functions in the API can
throw a memory error, and I do not see why pushstring deserves any
special treatment.


>  I don't see luaL_cpcall per se in the manual or source of 5.2-work2,
> though, so I can't really tell the details; perhaps I'm missing
> something.

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.


So, I guess it will boil down to this:

int pushaux (lua_State *L) {
  lua_pushstring(L, (char *)lua_touserdata(L, 1));
  return 1;
}


const char *ppushstring (lua_State *L, const char *s) {
  lua_pushlightuserdata(L, s);
  return (luaL_cpcall(L, pushaux, 1, 1) == LUA_OK) ? lua_tostring(L, -1) : NULL;
}

(This last function could be a macro.)

-- Roberto