Re: [ANN] lglob 0.8 Extended Globals Checker for Lua

[Petite Abeille <petite.abeille@...>]

On Apr 29, 2013, at 9:40 PM, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> wrote:

> There isn't enough information in 'luac -p -l' but there is in 'luac -p -l -l'.
> However, the list of locals is printed after the bytecode and one would need
> to read the whole listing to find SETTABLE and GETTABLE that use a local
> named _ENV.
> 
> This particular task is easier to program with lbci. The code at the end
> shows an example. However, it does not works in all cases; it is fooled
> by this code:

Thanks for the code example. 

But... now I'm a bit confused by what you consider a, err,  'global'… 

In the simple, original case… globals now returns all access to _ENV:

globals
	TestGlobal.lua	3	SET*	_NAME
	TestGlobal.lua	4	SET*	Foo
	TestGlobal.lua	5	SET*	Bar
	TestGlobal.lua	4	GET 	_NAME
	TestGlobal.lua	5	GET 	Foo

But… _ENV is not the global environment... _G is.

Contrast:

do
  local _ENV = {}
  _NAME = 'BAZ'
  function Foo() if _NAME then return end end
  function Bar() Foo() end
end

Which is equivalent to:

do
  local _ENV = {}
  _ENV._NAME = 'BAZ'
  function _ENV.Foo() if _ENV._NAME then return end end
  function _ENV.Bar() Foo() end
end


With:

do
  local _BAZ = {}
  _BAZ._NAME = 'BAZ'
  function _BAZ.Foo() if _BAZ._NAME then return end end
  function _BAZ.Bar() _BAZ.Foo() end
end

Neither variants access, nor set any globals. And yet,  the _ENV flavor reports 5 global access. As oppose the _BAZ flavor which reports none. As it should.  

What gives?