lua-users home
lua-l archive

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

Following up on my previous posts and with the suggestion of Peter Cawley on the return value, I come up with the following code suggestion (clipped from the auxlib):

LUALIB_API void *luaL_isuserdata (lua_State *L, int ud, const char *tname)
  void *p = lua_touserdata(L, ud);
  if (p != NULL)
  {  /* value is a userdata? */
    if (lua_getmetatable(L, ud))
    {  /* does it have a metatable? */
      lua_getfield(L, LUA_REGISTRYINDEX, tname);  /* get correct metatable */
      if (lua_rawequal(L, -1, -2))
      {  /* does it have the correct mt? */
        lua_pop(L, 2);  /* remove both metatables */
        return p; /* this is good! */
       lua_pop(L, 1);  /* remove 2nd metatable */
       lua_pop(L, 1);  /* remove 1st metatable */
  return NULL;  /* not what is wanted */

On 20 jun 2009, at 20:48, Hans van der Meer wrote:

On 20 jun 2009, at 20:24, Peter Cawley wrote:

On Sat, Jun 20, 2009 at 6:59 PM, Hans van der Meer<> wrote:
After which luaL_checkudata simply can become:
#define luaL_checkudata(L,A,N)\

No it cannot, as it would not then return the address of the userdata,
and furthermore, macro arguments other than L would be used multiple
times, which is a definite no-no in the Lua core.

Sorry I did not know about the no-no. Of course that should be respected.

I would not name the new function lua_isudata, as:
1) there is already the similar sounding lua_isuserdata
2) the function can be implemented in the aux library, so it would
have luaL_ prefix
3) I'd prefer luaL_touserdata rather than luaL_isuserdata, so that it
returns the pointer or NULL rather than 1 or 0

The exact naming and/or functionality is not important to me. I will gladly leave it to others to determine what is best. That userdata can be checked without an error stop is important, I think.

Your suggestion of returning a pointer or NULL is sensible. A separate call to lua_touserdata is avoided then. (Allthough I fear that some might object that this will seduce people to use the error prone constructs: if (!(a=call())) and such ;-)

I will be happy if something of this sort will be accepted in the near future.

Hans van der Meer