lua-users home
lua-l archive

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


On Mon, Jun 24, 2019 at 10:14 PM nobody <nobody+lua-list@afra-berlin.de> wrote:

> This is a GOOD thing.  I can't remember how often I had to add __index, __pairs, __tostring, … or added custom metamethods to make some other library work with my code.

As I said in another message, I do not mind having the metatable modifiable. I take issue with being able to suppress a C-language finalizer set by a C library to clean up its C data. Generalising from here would not be relevant in my opinion. One could argue the metatable is not how finalization of userdata ought to be controlled to begin with (the ship might have sailed, though).

> It boils down to this:  Do you trust the user to not intentionally break things?

"Intentionally" may or may not be part of this. But even if we stick with it, and even if we say "it should then be a sandbox", what is the solution?

I am not looking for an arbitrarily strict sandbox. My whole purpose is to run finalizers set up by C libs when they should run and reclaim associated resources. If the intended (still sticking with it) use of a library (i.e., without leaks) can bring my sandbox down, be it. Call it an intended mode of failure. I do not want unintended failure modes, especially not those caused by resource leaks.

So, why is the standard IO library not sandbox-friendly (in the strict sense clarified above) out of the box? Is it going to lose any (intended, since we are sticking with it) functionality by being sandbox-friendly? Is it because it is (too) hard to make it so? Perhaps we might think of a mechanism to make this straightforward? Or at least explain the tradeoffs somewhere?

As an aside, it is not accidental that I brought up this issue today. It should be viewed in the context of the general discussion of garbage collection, finalization and "closing" in Lua 5.4.

> Basically every time someone used __metatable, that broke or seriously interfered with my metaprogramming.

You are probably making a whole lot of good points in the discussion of __metatable that follows, and which is entirely absent in the manual and PiL (and Google, if my inept command of it counts for anything), which again demonstrates what I mentioned earlier: all this is arcane knowledge and one basically starts with the unsafe paradigm when writing a C library. Or a sandbox-friendly C library, if you must insist.

Cheers,
V.