Considering keep track of the index of global table

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Considering keep track of the index of global table

奥斯陆君王
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


Reply | Threaded
Open this post in threaded view
|

Re: Considering keep track of the index of global table

Tim Hill


> On Aug 15, 2018, at 9:17 AM, qtiuto <[hidden email]> 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.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Considering keep track of the index of global table

Dirk Laurie-2
Op Do., 16 Aug. 2018 om 00:59 het Tim Hill <[hidden email]> geskryf:
> > On Aug 15, 2018, at 9:17 AM, qtiuto <[hidden email]> 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.

As anything that would need an extra sentence in the User's Manual
tends to be :-)

There are of course certain properties of global _ENV that are
unilkely to be shared by other local variables,
such as 'v._ENV == v'.

And there are programming habits that force _ENV to be the first
upvalue, such as starting functions with 'local _ENV=_ENV'.

And there is a programming style, documented in PiL [1] no less, that
uses the idiom of putting _ENV in the parameter list.

Raffiniert sein die Lua-Erfinder, aber boshaft sein sie nicht.  —
Alberto Einsteinschy

[1] 3rd ed, p147.

Reply | Threaded
Open this post in threaded view
|

Re: Considering keep track of the index of global table

Tim Hill


> On Aug 16, 2018, at 12:14 AM, Dirk Laurie <[hidden email]> wrote:
>
> Op Do., 16 Aug. 2018 om 00:59 het Tim Hill <[hidden email]> geskryf:
>>> On Aug 15, 2018, at 9:17 AM, qtiuto <[hidden email]> 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.
>
> As anything that would need an extra sentence in the User's Manual
> tends to be :-)
>
> There are of course certain properties of global _ENV that are
> unilkely to be shared by other local variables,
> such as 'v._ENV == v'.
>
> And there are programming habits that force _ENV to be the first
> upvalue, such as starting functions with 'local _ENV=_ENV'.
>
> And there is a programming style, documented in PiL [1] no less, that
> uses the idiom of putting _ENV in the parameter list.
>
> Raffiniert sein die Lua-Erfinder, aber boshaft sein sie nicht.  —
> Alberto Einsteinschy
>
> [1] 3rd ed, p147.
>

Which is fine, but it makes it impossible to create a generic deep table persistence function that doesnt have to depend on the user following some convention or other. I dislike immensely such requirements; “All you have to remember is …” sounds fine until there are two dozen packages all with such “trivial” requirements. Such “trivia” quickly become overwhelming (and probably conflicting as well). Cognitive overload applied to software development.

—Tim


Reply | Threaded
Open this post in threaded view
|

Re: Considering keep track of the index of global table

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> > > 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.
>
> As anything that would need an extra sentence in the User's Manual
> tends to be :-)
>
> There are of course certain properties of global _ENV that are
> unilkely to be shared by other local variables,
> such as 'v._ENV == v'.
>
> And there are programming habits that force _ENV to be the first
> upvalue, such as starting functions with 'local _ENV=_ENV'.
>
> And there is a programming style, documented in PiL [1] no less, that
> uses the idiom of putting _ENV in the parameter list.

I think this discussion misses the main point. Functions that represent
chunks always have _ENV as the first upvalue, no matter what the
programmer writes. Much more often than not, load is used to load that
kind of "function" (whole chunks). The facility of setting the first
upvalue to the global table is directed to this (very frequent)
case. For any other case, the programmer should use 'debug.setupvalue',
independently of whether the upvalue is _ENV.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Considering keep track of the index of global table

Egor Skriptunoff-2
In reply to this post by Tim Hill

On Thu, Aug 16, 2018 at 1:59 AM, Tim Hill <[hidden email]> wrote:

> On Aug 15, 2018, at 9:17 AM, qtiuto <[hidden email]> 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.