Re: Meta function tables for LUA_FILEHANDLE: why two separate tables?

[Sean Conner <sean@...>]

It was thus said that the Great Viacheslav Usov once stated:
> On Sat, Nov 19, 2022 at 12:30 AM Sean Conner <sean@conman.org> wrote:
> 
> >   I am wondering just how much of an issue this is.  Have you encountered
> > Lua code that wantonly changed or called __gc() diretly?
> 
> "I am wondering just how much of an issue this is. Have you
> encountered any code that wantonly overruns that stack-based buffer?"

  Yes I have.  Ball's back in your court.  Have you encoutered *any* code
that deleted or changed __gc() directly?

> > [1]     The only one I've seen is luafilesystem
> 
> I am unsure we are talking about the same thing. 

  I think you're right about that.

> What I see at
> https://github.com/lunarmodules/luafilesystem/blob/master/src/lfs.c
> is, for example:
> 
>   lock = (lfs_Lock *) lua_newuserdata(L, sizeof(lfs_Lock));
>   lock->fd = fd;
>   luaL_getmetatable(L, LOCK_METATABLE);
>   lua_setmetatable(L, -2);
> 
> This is the Win32 version of lock(), and, if __gc has been
> obliterated, it will leak the handle of the lock file and fail to
> delete the lock file. 

  Yeah, and if __gc had been opliterated on the file handle, it would fail
to close.

> Speaking of the Win32 version, I believe there is another bug there:
> 
>   fd = CreateFile(ln, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS,
>                   FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL);
>   free(ln);
>   if (fd == INVALID_HANDLE_VALUE) {
>     return lfs_win32_pusherror(L);
>   }
> 
> free() may change the "last error" value of the current thread, and
> lfs_win32_pusherror() will then fail to report it properly.

  Have you reported these issues then?  

  -spc