Re: Lua 5.0 and globals (long)

["Wim Couwenberg" <w.couwenberg@...>]

Hi,

> In particular,
> setglobals/ getglobals should never be part of a sandbox. If you do not
> have getglobals, all problems about stealing disapear ("traps" 2, 3, and
> 4).

Indeed.  But somehow it's a pity that the simpler Lua 4 scheme supports
sandboxing easily and still allows the globals call inside of the sandbox.

> - about missing levels: as already explained, that was a bug. You still
> cannot change the environment of a function that ended in a tail call,
> but you do not get wrong results.

But it is the tailcall _itself_ that is skipped, not the function that ends
in a tail call (or did you mean this by the "bug"?)  So getglobals(2) can go
way up the call level nesting...  Here's an example (does this give the
"right" result?)

function a() y = "a" return b() end
function b() y = "b" return c() end
function c() return getglobals(2).y end

y = "global"
setglobals(a,{b = b})
setglobals(b,{c = c})

print(a())  -- prints "global" !?!

The observation that the result of a getglobals(2) call is "inherently
unpredictable" was based on your earlier proposition to throw an error if a
certain stack level is missing (if I understood correctly.)  So you either
get a globals table, or an error, but which one??

> Moreover, there is no tail call when
> you call a C function, so "loadfile" always get the correct environment.

Yet another thing that I learn about globals...  :-)  Nonetheless, what if
loadfile is called from within a function that is itself called as a tail
call?  Again, you skip that level... is that right?

> - "require" is a different thing.
[.. snip snip ..]

I think it's common that packages require other ones, so I would like to
allow require in a sandbox.  Again, it comes down to disallowing the
get/setglobals calls (see my final comment below.)

> - you say "that a function is likely to return or produce closures
> with different globals than those locally in effect is almost always
> confusing." I did not understand that point. A function always produces
> closures with the globals locally in effect.

Ah, that's my talent of not making myself clear!  I meant the following:
suppose that some function f returns say, a generator (like string.gfind).
Then that generator will likely share the globals of f, instead of the
"current" globals.  It's not that this is a bug or something, but I tend to
mentally discard this fact, even after spending quite some time with Lua
5.0.  Here's an example:

-- set global x
x = "aap"

-- subscope the globals
local c = {}
setmetatable(c, {__index=getglobals(1)})
setglobals(1, c)

-- set x in subscope
x = "noot"

-- test a generator...
y = string.gfind("my name is Wim", "name")
print(getglobals(y).x)  -- prints "aap"

> Anyway, I've got the overall idea that the main problem is not the
> environments per si, but the set/getglobals functions. We will not
> change anything for 5.0 final (only their names), but we may change
> those functions for 5.1, after all of us have more time to learn how
> to use them.

I largely agree.  To be honest, if _I_ had to decide what to do with the
globals in Lua 5.1 I surely wouldn't know yet.  But I'm quite certain that I
_would_ do away with the set/getglobals calls on closure or stack level
arguments!

Bye,
Wim