Re: bug in lauxlib.c : new explanation

[Francisco Olarte <folarte@...>]

On Thu, May 14, 2020 at 9:57 PM Massimo Sala <massimo.sala.71@gmail.com> wrote:
> Roberto Ierusalimschy wrote:
> I still fail to see the bug. What is the problem if the error reported is a real error in 'fclose' instead of the previous error
> Obviously I disagree with Roberto :-)
> The function must return the first error condition, any other solution is unreliable so useless.

Are you still talking about loadfilex? As I see doc states

"This function returns the same results as lua_load, but it has an
extra error code LUA_ERRFILE for file-related errors (e.g., it cannot
open or read the file). "

and lua_load says:

"Loads a Lua chunk without running it. If there are no errors,
lua_load pushes the compiled chunk as a Lua function on top of the
stack. Otherwise, it pushes an error message. "

Nowhere does it say it pushes the eigen-error message.

fclose could be moved around and duplicated in both ( ok and error )
return code paths, but given you normally do not encounter errors when
closing readonly stdio files  ( in which case fclose must not touch
errno ) I think it is not worth the hassle.

On my Debian system fclose(3) states
ERRORS
       EBADF  The file descriptor underlying stream is not valid.

       The fclose() function may also fail and set errno for any of
the errors specified for the routines  close(2),  write(2),  or
       fflush(3).
Ignoring write and fflush, which do not normally play on read only,
close(2) says..
ERRORS
       EBADF  fd isn't a valid open file descriptor.

       EINTR  The close() call was interrupted by a signal; see signal(7).

       EIO    An I/O error occurred.

       ENOSPC, EDQUOT
              On NFS, these errors are not normally reported against
the first write which exceeds the available storage space, but
              instead against a subsequent write(2), fsync(2), or close(2).

So it seems ignoring fclose errors is not going to hurt too much. You
may get an EIO on some exotic filesystem, or an EINTR, but the other
ones seem pretty unlikely.




> I am a newbie in the "Lua ecosystem".
> Every software has bugs, big and small.
> Lua is an excellent tool; we can only improve it.

Sending the original error message instead of a potential fclose
related one is not a bug fix, it's an improvement. You can substitute
the wole errfile() with "pushstring("IOERROR"), return LUA_ERRFILE"
and still will not be a bug.

Francisco Olarte.
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org