Re: cannot index a table loaded as a chunk - solved, and a bug?

[Rici Lake <lua@...>]

The definition of lua_dofile is in lib/lauxlib.c:

static int aux_do (lua_State *L, int status) {
  if (status == 0) {  /* parse OK? */
    status = lua_pcall(L, 0, LUA_MULTRET, 0);  /* call main */
  }
  callalert(L, status);
  return status;
}

LUALIB_API int lua_dofile (lua_State *L, const char *filename) {
  return aux_do(L, luaL_loadfile(L, filename));
}

No magic there: it calls luaL_loadfile, if that works, it calls the 
chunk.
If it doesn't work, calls callalert, which tries to call the global 
_ALERT,
and otherwise prints the string on stderr:

_ALERT, as far as I know, is undefined by default. If you are in an
environment which redirects stderr to /dev/null or equivalent, then you 
will
see nothing.

So that might be your problem with lua_dofile. I think I have seen other
people with the same problem, also using the same OS. In any event, 
lua_dofile
is deprecated as I understand it.

Now, the error message itself is quite clear: NULs are not legal 
characters
in a Lua program, except inside comments and strings. (And probably 
unwise
there, also.) So where is the NUL coming from? Based on a problem 
someone
else mentioned in a completely different environment, I am wondering if 
some
modern versions of the unnamed operating system don't return a UTF16 
ctl-z (eof
indicator) at the end of a file under certain circumstances, possibly 
when the
file did not end with a cr/lf. This is just a wild guess, but it could 
be
confirmed with a hexdump if you had such a utility kicking around.

Perhaps Lua *should* ignore NULs (and possibly other control characters)
rather than complaining about them. But as far as I can see, it works 
the
way it is documented to work; editors and/or C libraries ought not to
invent control characters, in my humble opinion, and the bug report 
ought
to go to those responsible.

Rici

On 20-Aug-04, at 7:58 PM, Michael Newberry wrote:

> Small correction to my previous post. The actual error message is 
> "...near
> char(0)", not "...new char(0)", like this:
>
> >     (chunk filename) :68: invalid control char near 'char(0)'
>
> Michael