lua-users home
lua-l archive

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

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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.

AltStyle によって変換されたページ (->オリジナル) /