Re: Considering keep track of the index of global table

[Egor Skriptunoff <egor.skriptunoff@...>]

On Thu, Aug 16, 2018 at 1:59 AM, Tim Hill <drtimhill@gmail.com> wrote:

> On Aug 15, 2018, at 9:17 AM, qtiuto <qtiuto@gmail.com> wrote:
>
> While lua_load will always set the first upvalue of a dumped function to the global table, the actual index of the global table is related to the first time it's used in the function.If some local value is used
> first,then its upvalue index will be lower than _ENV.
> What's worse,if I use strip mode, I can't figure out the actual index of the _ENV when I load it.So, it would  better add one more int in dumped content to keep track of the global index and when load it, set its value to global table,rather than trying to figure out whether it has one more upvalue after undump, and setting the first value to the global value.It will cause a bug!
>
> The fix is little.However, I don't want to type it in my phone

I suggested something like this when I was writing a “deep” table dump function (so I could dump complete closures). It was politely declined.

Could you explain how that information (position of _ENV in the list of all upvalues) might be useful for you?
IMO, you don't need this information to save and resurrect (serialize and deserialize) a closure.
When dumping a closure, values of all its upvalues (including _ENV upvalue) should be serialized too.
There is no need for treating _ENV upvalue in a special way, so there is no need to know _ENV upvalue's index.
And I hope, your table serializer is clever enough to avoid deep-dumping _G.
 
 
In the following situation it would be impossible to determine which upvalue is the _ENV:
 
   local t1, _ENV, t2 = ...
   local function f()
      t1.print"Hi"
      print"Hi"
      t2.print"Hi"
   end
   deep_dump(f)
 
You will be unable to restore source text of this function correctly from its dump; this is really a problem for Lua decompiler writers.
But this is not a problem for closure-serializer writers.