lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

It was thus said that the Great Viacheslav Usov once stated:
> On Sat, Nov 19, 2022 at 12:30 AM Sean Conner <> 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
> 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,
>   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?