Re: Protect global table from any changes

[Flyer31 Test <flyer31@...>]

If you want to implement read-only data, you have to distinguish
mainly also between "pre-defined read-only" or "run-time read-only".

Pre-defined read-only I think is somehow at least prepared / planned
not for future Lua versions by introduction of the variable qualifier
const. As I see it, this is not really used yet (it can be very useful
mainly in restricted RAM controller applications, as then mainly e. g.
literal strings can possibly "sleep in ROM" in some furture ... just
large systems as already PCs usually anyway always use "RAM-only"
approach for Data+Code (so called von-Neumann-architecture in contrast
to the typical Microcontrollers with separated RAM and ROM and RISC
instruction set, e. g. ARM,...).

But as I understand you, you would like to have run-time read only. So
a method to freeze e. g. _G during runtime and then somehow perhaps
another command to "unfreeze" it again at some later time. So that
sandboxing _G would somehow work quite easily by just re-aligning this
unfreeze function to an empty function and then freeze _G. Just then
of course inside the sandbox it will be not allowed to construct any
"new function" sand castles e.. g. ... so the fun factor in such a
sand box might decrease significantly :).



On Thu, Jan 20, 2022 at 10:19 PM Petri Häkkinen <petrih3@gmail.com> wrote:
>
>
> On 20. Jan 2022, at 22.38, Coda Highland <chighland@gmail.com> wrote:
>
> 
> On Thu, Jan 20, 2022 at 1:24 PM Petri Häkkinen <petrih3@gmail.com> wrote:
>>
>> Luau (Roblox’s custom Lua implementation) does it right by allowing flagging any table as read only. Trying to modify a read only table raises an error.
>>
>> Since the branches needed to implement this inside the VM are very coherent, the performance overhead is pretty small. I think it would make sense for Lua to support this as well.
>>
>> Petri
>
>
> VM modifications aren't necessary from a semantic perspective. As has been mentioned: You can already implement read-only tables and have been able to for quite a long time. You have also been able to make proxies for a very long time, allowing each script's environment to "inherit from" the base environment without permitting modifications back to it. Doing it this way has pretty low memory overhead (you aren't duplicating the entire environment per script) and the performance isn't THAT much worse in practice.
>
> Implementing it into the VM would be an optimization, not something necessary for functionality. This is why we have a wiki page for useful patches that some people might find valuable. Vanilla Lua is primarily focused on keeping a streamlined, elegant implementation, and new features are typically introduced in response to an obvious need that can't be handled in Lua code.
>
> /s/ Adam
>
>
> Yeah I know. But there are many other redundant features in Lua and pretty much any language. For example, for, while, * and closures. Just a few random examples.
>
> It’s about finding the right balance; minimalism is a good principle but going too far with it is not pragmatic. In my opinion, the usefulness of native read only tables more than compensates the small increase in complexity and performance cost to the VM.
>
> Petri