Re: Ravi bug related to setting of L->top in OP_RETURN

[Dibyendu Majumdar <mobile@...>]

On 5 August 2015 at 20:54, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> It seems to me that there is an assumption that a Lua function will
> never run another Lua function via luaV_execute() - that only C
> functions can invoke luaV_execute()?
>

Since there is the following assertion :

          if (b) {
            L->top = ci->top;
          }
          lua_assert(isLua(ci));
          lua_assert(GET_OPCODE(*((ci)->u.l.savedpc - 1)) == OP_CALL);

then I conclude above is true when the Lua function was invoked by OP_CALL.

>>
>> When 'b' is zero, this return must return all values on the stack
>> (e.g., 'return ...', and L->top must be kept for the next instruction
>> (after the OP_CALL to where we are returning) to know how many
>> results the function have (see next answer).
>>
>> It happens when the function that called the one being returned needs
>> multiple returns. As I explained, in that case L->top limits the
>> number of values being returned, and will be corrected by the
>> instruction following the OP_CALL (see comments in 'lopcdes.h').
>>
>

I see that 'b' is being used to determine how many results to return
in above, but in OP_RETURN, 'L->top' is immediately reset so is it
correct to say that 'L->top' must be kept for the next instruction
after the OP_CALL?

Regards