Is lua_getglobal exposed at the Lua level?

[Dirk Laurie]

Global variables?

Well, of course there is no such thing. The manuall tells us so.
"The Lua library is fully reentrant: it has no global variables."
And as we all know, what looks like a global variable 'var' in a Lua
5.2 or 5.3 script is just syntactic sugar for '_ENV.var'.

The API nevertheless talks like there are global variables:

int lua_getglobal (lua_State *L, const char *name);
Pushes onto the stack the value of the global 'name'. Returns the
type of that value.

Are these globals the same thing as global variables in a Lua script?

Let's see. These refer to table entries in "the global environment
stored at index LUA_RIDX_GLOBALS in the registry". (RIDX means
registry index).

So they are the same if and only tf "the global environment" is the
same as _ENV. This is the case when you start up Lua, but if you
fiddle around with _ENV, it does not mean that "the global
environment" is different too, only that you can no longer see it
(unless of course you were prudent enough to have stored _G in a local
variable).

So is 'lua_getglobal' exposed at the Lua level? In other words, is
there anything you can do to retrieve an original global variable if
_ENV has changed? Obviously you can if you copied over either _G or
the debug library. Any other way?

[Jonathan Goble]

Post by Dirk Laurie
Global variables?
Well, of course there is no such thing. The manuall tells us so.
"The Lua library is fully reentrant: it has no global variables."

That's referring to C globals within the C code.

Post by Dirk Laurie
And as we all know, what looks like a global variable 'var' in a Lua
5.2 or 5.3 script is just syntactic sugar for '_ENV.var'.
int lua_getglobal (lua_State *L, const char *name);
Pushes onto the stack the value of the global 'name'. Returns the
type of that value.
Are these globals the same thing as global variables in a Lua script?

Of course. The Lua language has plenty of global variables. It's just the C
code that implements Lua that doesn't.

Post by Dirk Laurie
Let's see. These refer to table entries in "the global environment
stored at index LUA_RIDX_GLOBALS in the registry". (RIDX means
registry index).
So they are the same if and only tf "the global environment" is the
same as _ENV. This is the case when you start up Lua, but if you
fiddle around with _ENV, it does not mean that "the global
environment" is different too, only that you can no longer see it
(unless of course you were prudent enough to have stored _G in a local
variable).
So is 'lua_getglobal' exposed at the Lua level? In other words, is
there anything you can do to retrieve an original global variable if
_ENV has changed? Obviously you can if you copied over either _G or
the debug library. Any other way?

This is an interesting question, though.

[Gé Weijers]

Post by Dirk Laurie
So is 'lua_getglobal' exposed at the Lua level? In other words, is
there anything you can do to retrieve an original global variable if
_ENV has changed? Obviously you can if you copied over either _G or
the debug library. Any other way?

That's a no. _ENV is set when a chunk is compiled. If you specify a
different value for the environment for a chunk and you do not provide
access (direct or indirect) to the global environment you have no access to
that global environment. This is a feature, otherwise you could not build a
sandbox.

--
Gé

[Roberto Ierusalimschy]

Post by Gé Weijers
That's a no. _ENV is set when a chunk is compiled. If you specify a
different value for the environment for a chunk and you do not provide
access (direct or indirect) to the global environment you have no access to
that global environment. This is a feature, otherwise you could not build a
sandbox.

Gé's last sentence is crucial in this discussion.

-- Roberto

[Dirk Laurie]

Op Di. 13 Nov. 2018 om 18:57 het Roberto Ierusalimschy

Post by Roberto Ierusalimschy

Post by Gé Weijers
That's a no. _ENV is set when a chunk is compiled. If you specify a
different value for the environment for a chunk and you do not provide
access (direct or indirect) to the global environment you have no access to
that global environment. This is a feature, otherwise you could not build a
sandbox.

Gé's last sentence is crucial in this discussion.

Apart from 'debug' and '_G', the sandbox must also not contain the
library functions 'load' and 'loadfile'.

local load = load
_ENV = {print=print}
getglobal = function(name)
return load("return "..name)()
end
print(getglobal"math".pi) --> 3.1415926535898

[Tim Hill]

Post by Dirk Laurie
Global variables?
Well, of course there is no such thing. The manuall tells us so.
"The Lua library is fully reentrant: it has no global variables."
And as we all know, what looks like a global variable 'var' in a Lua
5.2 or 5.3 script is just syntactic sugar for '_ENV.var'.
int lua_getglobal (lua_State *L, const char *name);
Pushes onto the stack the value of the global 'name'. Returns the
type of that value.
Are these globals the same thing as global variables in a Lua script?
Let's see. These refer to table entries in "the global environment
stored at index LUA_RIDX_GLOBALS in the registry". (RIDX means
registry index).
So they are the same if and only tf "the global environment" is the
same as _ENV. This is the case when you start up Lua, but if you
fiddle around with _ENV, it does not mean that "the global
environment" is different too, only that you can no longer see it
(unless of course you were prudent enough to have stored _G in a local
variable).
So is 'lua_getglobal' exposed at the Lua level? In other words, is
there anything you can do to retrieve an original global variable if
_ENV has changed? Obviously you can if you copied over either _G or
the debug library. Any other way?

Or, for “lua_getglobal()” read “lua_getfromdistinguishedenvironment()”.

—Tim