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

["Michael Newberry" <mnewberry@...>]

Rici,

I agree with what you say. I believe it was the lack of clear error messages
from lua_dofile() that caused the problem. This occured in old code that
used lua_dofile and had not been changed. However, we did change the main
script execution method to use luaL_loadfile() and lua_pcall(). But we
missed changing our Include() function. I am guessing that the lack of
specific error messaging is at least part of the reason lua_dofile has been
deprecated in the latest lua releases.

Michael

----- Original Message ----- 
From: "Rici Lake" <lua@ricilake.net>
To: "Lua list" <lua@bazar2.conectiva.com.br>
Sent: Friday, August 20, 2004 6:14 PM
Subject: Re: cannot index a table loaded as a chunk - solved, and a bug?


> 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
> >
>