Re: Determining if _ENV is the first upvalue of a closure?

[Dirk Laurie <dirk.laurie@...>]

2015-03-13 6:28 GMT+02:00 Tim Hill <drtimhill@gmail.com>:

> For various reasons we need to dynamically move Lua functions (actually
> closures) across lua_State boundaries.

This seems to indicate that you have full control over all those states and
over the source code of the functions.

> The problem occurs with _ENV. Of course we don’t serialize the environment
> (nor could we), so we skip the first upvalue. However, not all functions
> *have* _ENV as the first upvalue, since the compiler only emits this if it
> is used in the function.

If you put say `local _ENV=_ENV` as first line, you force _ENV to be the first
upvalue except if it has a parameter _ENV.

> The problem then, is determining which functions have _ENV as an
> upvalue and which do not. I’m unable to find a deterministic way to do this.
> I can’t look at the name of the first upvalue, since this can be stripped out
> with debug information.

If you have control over the dumping of those functions, you can force
no-stripping, e.g. by doctoring string.dump before giving control to a
program that dumps functions.

Doing so has the added advantage that you can dispense with the need
to know the numbers of the other upvalues.

    my_upvals = {upval_1 = val1, ...}
    for i=1,255 do -- there can't be 256 upvalues
       local val,name = debug.getupvalue(func,i)
       if name==nil then break end
       debug.setupvalue(f,i,my_upvals[name])
    end

All this suggests that one should request a feature whereby string.dump
has a more sophisticated second argument which can be used to select
which categories should be stripped. `nil` then obviously means
`don't strip anything`. I can imagine a scenario in which one would not
want to expose actual source code, but would be willing to provide
an API naming the upvalues.