Re: lua_[g/s]etupvalue and debug stripping

[Roberto Ierusalimschy <roberto@...>]

> I'm writing some 5.1-based modules that uses lua_getupvalue and
> lua_setupvalue. By default, when building in release mode, the platform I'm
> targeting strips debug info, and the code in question breaks.
> 
> Looking into the Lua source suggested that the `if (name)` branch in those
> two functions is being skipped; basically, sizeupvalues is turning up 0 on
> me and aux_upvalue early-outs. (I see that in 5.2 and 5.3 aux_upvalue takes
> more pains to return a string, but it seems this must be accounting for a
> different scenario?)

The whole coding of upvalues changed from 5.1 to 5.2. In 5.1,
the (non-debug) information about upvalues were "buried" in the opcode
that created the closure. In 5.2, that information went to the 'upvalues'
array, along with the debug info (the names of the upvalues). So,
in 5.1 with no-debug information, the whole array was stripped, resulting
in (sizeupvalues == 0). In 5.2, the array is still there, only the
'name' fields are stripped.


> With the following change to the Lua closure part
> 
>     Proto *p = f->l.p;
>     const char * str;
>     if (!(1 <= n && n <= f->l.nupvalues)) return NULL;
>     *val = f->l.upvals[n-1]->v;
>     str = p->sizeupvalues ? getstr(p->upvalues[n-1]) : NULL;
>     return (str == NULL) ? str : "(*no name)";
> 
> I seem to be reliably getting upvalues again. However, I'd be interested to
> know if I'm violating any other assumptions.

It seems correct. But it could avoid testing the same condition twice:

    return  p->sizeupvalues ? getstr(p->upvalues[n-1]) : "(*no name)";

-- Roberto