[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Ravi bug related to setting of L->top in OP_RETURN
- From: Dibyendu Majumdar <mobile@...>
- Date: Sat, 15 Aug 2015 14:11:11 +0100
On 13 August 2015 at 04:47, 云风 Cloud Wu <cloudwu@gmail.com> wrote:
>
> Dibyendu Majumdar <mobile@majumdar.org.uk>于2015年8月13日周四 上午6:56写道:
>>
>>
>> My original problem was that the the behaviour of luaV_execute() is
>> different from the way a Lua function returns from OP_RETURN. So I
>> think maybe this is the only case that is interesting from the point
>> of view of resolving the original issue.
>
>
> In my opinion, the difference of the behaviour is the place of results
> rather than who calls.
>
> When a C function call lua function via luaV_execute(), the place of results
> always on the top of stack;
>
> If a lua function be called via OP_CALL , the place of results may be in the
> stack frame if the number of results is fixed. Or it's on the top of stack
> when the results used as vararg , and it need expands the L->top.
I wasn't able to understand your description above - I think you mean following:
When C function calls luaV_execute() - luaV_execute() upon returning
always has L->top pointing to the top of the results being returned.
(I think I understand why this is - it is the only way for
luaV_execute() to inform the caller of the number of return values).
When Lua function is called via OP_CALL and the number of values being
returned is fixed - L->top is reset to the caller's Ci->top. But if
variable number of results are being returned then L->top is left
where it is (i.e. pointing to the top of the results) so that OP_CALL
knows how many values were being returned.
>
> The responsibility of moving results to the right place is luaD_poscall ,
> but it always change the L->top.
luaD_poscall() moves the results and always leaves L->top pointing to
the top of the results.
I understand and agree so far.
> When the results is in the stack frame, we
> shouldn't change the L->top, so it returns a signal and let OP_RETURN
> changes back.
>
I think as it stands if luaD_poscall() does not leave L->top point to
the top of the results then external callers of luaV_execute() will
not know how many values were returned.
Thanks and Regards
Dibyendu