It was thus said that the Great Marc Lepage once stated:
> Apologies for another silly little question.luaL_checkudata() will raise an error if the item at the given stack index
> In C code, for 5.1, if I call luaL_checkudata but the index doesn't exist
> (say I was expecting an arg but none was provided), is that OK (and I get
> expected failure) or is that somehow bad or undefined?
does not exist, or isn't a userdata. This error can be caught by pcall()
(in Lua) or lua_pcall() (in C) but I rarely do that in my code.
But it calls luaL_typerror() when lua_touserdata() returns NULL, and it's
> In the implementation, I can see it calls:
> lua_touserdata: If the value at the given acceptable index is a full
> userdata, returns its block address. If the value is a light userdata,
> returns its pointer. Otherwise, returns NULL.
luaL_typerror() that causes the error to be raised (even though
luaL_checkudata() looks as if it returns NULL, that statement is never
reached and exists, as the comments there says, to keep compilers from
I wouldn't worry about it. Here's some C code :
> So I guess my question is whether, if I was expecting an arg and it wasn't
> provided, is that an "acceptable index?" (Or, if it's not acceptable,
> that's the "otherwise" clause?)
static int tcclua_define(lua_State *const L)
And if that function is called with no parameters:
Lua 5.1.5 Copyright (C) 1994-2012 Lua.org, PUC-Rio
> tcc = require "org.conman.tcc"
> cc = tcc.new()
stdin:1: bad argument #3 to 'define' (string expected, got no value)
[C]: in function 'define'
stdin:1: in main chunk
Call it correctly though:
And everything is fine.
-spc (So, why does it trigger on parameter 3 first? Because of the rules
of C when evaluating parameters of a function---they're evaluated
from right to left. Why that way? I'll leave that as an exercise
for the reader ... )
 Part of a Lua interface to TCC . Code can be views here
 I based the code on the following TCC codebase: