|
It was thus said that the Great Iurii Belobeev once stated:
> Hi,
>
> I have the code:
>
> printf("errno: %d\n", errno);
> lua_getglobal(L, "require");
> lua_pushliteral(L, "mymodule");
> lua_call(L, 1, 1);
> printf("errno: %d\n", errno);
>
> package.cpath:
> /mydir/?/?.so
>
> mymodule exists:
> /mydir/mymodule/mymodule.so
>
> It is being required successfully.
>
> The wrong thing here for me is that errno is set to 2 (No such file or
> directory) after the successful require.
> It gives me some trouble later.
> Is such behavior expected here?
> Or I'm doing something wrong?
Yes, such behavior is expected, as it is an interaction between the C
standard and Lua's behavior. First, the C standand, section 7.5.3: errno.h
The value of errno is zero at program startup, but is never set to
zero by any library function. The value of errno may be set to
nonzero by a library function call whether or not there is an error,
provided the use of errno is not documented in the description of
the function in this International Standard.
Section 7.19.5.3.8: fopen() states:
The fopen function returns a pointer to the object controlling the
stream. If the open operation fails, fopen returns a null pointer.
There is no mention of errno in this function, so fopen() can set errno.
The Lua manual, in the section about package.searchers[] (an array), states
that the default order of module searching is:
1 search package.preload[]
2 search for a file specified in package.path
3 search for a file specified in package.cpath
4 search for a file specified in package.cpath (different criteria)
The second searcher will call fopen() on each segment in package.path,
causing errno to be set to the error seen. No C library (per 7.5.3) will
ever reset errno to 0, and Lua only sets errno to 0 in two places (as I can
see): once in io_pclose() (when closing a pipe), and os_execute() (before
running the standard C call system()).
I would not expect errno to be of much use after calling into Lua.
-spc