Re: Install __newindex for _G in C

[Flyer31 Test <flyer31@...>]

Hi Jonathan,
thank you again, very helpful... .

Concerning the last point: I would define my strbuf's like this (my
naming convention for them now would be SB... and into _G I will put
them as _sb_SB..., this name transfer is then handled automatically by
_G __newindex / __index, which now will fire always, as SB... never
will exist in _G (only in form of _sb_SB...)):
SBtmp= stringbuf.new( 100)

The dangerous thing now would be, if the user by some accident would program:
SBtmp= 'hallo'

Then I do not want the standard Lua thing to happen (that by strbuf
SBtmp switches somehow to a string...), but instead I want to copy the
string 'hallo' into my strbuf SBtmp.

With this __newindex thing of the _G table I control this nicely, and
anyway all my strbufs should be globals, this makes most sense... .

So I want also to avoid, that some user by some accident writes:
local SBtmp= stringbuf.new(100)

... as soon as the user then would program then any strbuf operation
(leading to my strbuf __newindex / __index / __concat...), then an
error will fire, as any such function will check whether _sb_SB... is
available in the _G table... . So it will recognize nicely any "local
misusing", and also if some user by some accident tries to create some
other name (e. g. sbtmp or tmp or something else...).

I am really very happy now I think, thank you... .

On Thu, Oct 14, 2021 at 10:52 PM Jonathan Goble <jcgoble3@gmail.com> wrote:
>
> On Thu, Oct 14, 2021 at 4:33 PM Flyer31 Test <flyer31@googlemail.com> wrote:
>>
>> Thanks - no comment to lua_setmetatable and luaL_setmetatable - this
>> really is awkward, but things like this sometimes happen in large
>> systems/documentations (and in Lua this is the first REALLY awkward
>> naming I encounter... of course somehow impossible to correct now, I
>> understand this... ).
>
>
> There are definitely some things in the C API that could be named better, agreed. This is a prime example. luaL_setmetatable is rarely used though, I would guess, as for its intended purpose, luaL_newmetatable is usually simpler.
>
>>
>> Concerning __index and __newindex thank you for your enlightening
>> comment ... . Concerning __index this was not really clear to me ...
>> but my strbuf userdata clearly IS something which you call proxy... as
>> it has no real indices... it just uses this writing to fire __index /
>> __newindex (but I think userdata very typically will do something like
>> this in most cases..).
>
>
> Correct, a userdata never has "valid indices" and so __index and __newindex will fire every time for a userdata. All indexing operations on userdata must pass through one of those two metamethods.
>
> Conversely, for tables, __index and __newindex behave in the manner I described (firing only if that key does not exist or is nil).
>
>>
>> Concerning the _G table I really could consider to use this, E.g. if
>> __newindex is fired for a key starting with "Buf...", then in my
>> __newindex function I would extend it to __strbuf__Buf..., , so then
>> __newindex and __index will fire any time, Buf... is accessed... . But
>> maybe I should better sleep over this, whether I really want to do
>> this ... but it is somehow quite a smart and possible idea I think...
>
>
> Rather than mangle the name (where the user could manually create that name and bypass your metamethods), it would be better to store them in a separate table without mangling and have the __index and __newindex functions be the only way to access that table (e.g. by closures, using lua_pushcclosure and lua_upvaluejoin). Then the "real" values would be inaccessible except through the metamethods (and the debug library, which is generally the first thing you should remove when sandboxing).
>
>>
>> Would you have a hint, how to fire an error, if a user then tries to
>> produce a local strbuf variable? (this really would not make too much
>> sense ... the main advantage of this strbuf buffers is the malloc only
>> ONCE, but if you use them locally, you can as well work just with
>> strings I think...). So somehow my userdata strbuf __index/ __newindex
>> functions should be able to check, whether they are in the _G table,
>> but this really is very straight forward...
>
>
> I'm not sure what you're asking here? (Admittedly, I haven't read the entire thread in detail since I am currently sick with a cold, so maybe I'm missing something obvious.)