Re: Strange Lua behavior with __eq return values

["Leo Razoumov" <slonik.az@...>]

On 11/21/08, KHMan <keinhong@gmail.com> wrote:
> Leo Razoumov wrote:
>
> > On 11/20/08, Matthew Paul Del Buono <delbu9c1@erau.edu> wrote:
> >
> > > Hi list,
> > >
> > > [..snip..]
> > >
> > >  I see that it should be executing the line "return (h(op1, op2))" but
> that's not what I seem to get in response. I would expect "true" to be the
> result if the manual stated "return not not (h(op1, op2))" but it doesn't.
> > >
> > >  Is this a manual problem, a Lua problem, or am I missing something?
> > >
> > >
> >
> > Apparently, the manual and the actual Lua implementation do differ.
> >
> > In the function "luaV_equalval" defined in  "lvm.c" the last two line are
> >
> >  callTMres(L, L->top, tm, t1, t2);  /* call TM */
> >  return !l_isfalse(L->top);
> >
> > that essentially mean "return not not (h(op1, op2))" as you correctly
> guessed.
> > It is different from the pseudo-code in the manual. I would suggest to
> > correct the manual.
> >
>
>  luaV_equalval needs to return a boolean 0 or 1 for comparison with the
> boolean value in field A in the OP_EQ opcode implementation. This is a
> straight int comparison, so a 0 or 1 value is mandatory. So in the manual,
> the pseudo-code's return type of boolean is implicit.
>

Yes, in C-code it has to be 1 or 0. This is precisely the reason, why
the Lua manual should be more specific about explicitly mentioning the
cast from h(op1,op2) to the boolean value. IMHO, the way manual has it
now contradicts to the actual Lua implementation.

--Leo--