lua-users home
lua-l archive

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

On Jan 22, 2011, at 11:09 AM, David J. Slate wrote:
One would hope that fixing this bug would be a priority for finishing
up Lua-5.2 and LuaJIT-2.0.

Yes.  It would be good to get confirmation from Rio and
Mike Pall, that they understand this is still an
outstanding bug.  The comment in the Lua 5.2.0-alpha test
suite (constructs.c, lines 25-27) hints that this was
considered an "old bug" (i.e., a fixed bug), yet the test
cases there only test for one of the three distinct
(known) expression patterns that cause the faulty results.

The patch at, which
has been applied in Lua 5.2.0-alpha, fixes this case:

Lua 5.1.4  Copyright (C) 1994-2008, PUC-Rio
> print((1 or false) and true or false)
1    -- Wrong! (Lua 5.2.0-alpha correctly prints 'true')

The patch, however, does not fix the following two:

Lua 5.2.0 (alpha)  Copyright (C) 1994-2010, PUC-Rio
> print((1 or 2) and true or false)
1    -- should print 'true'!

> print((nil and true) or false and true)
nil  -- should print 'false'!

The Lua 5.2.0-alpha test suite appears to test for that
last expression with this line:

assert((((nil and true) or false) and true) == false)

but actually doesn't, since the extra parentheses change
the meaning of the expression (remember 'and' has a
higher precedence than 'or').

I've tried to figure out a fix, but I don't understand
Lua internals enough yet.  I have found that the attached
patch fixes all three of the problem expressions, but
does so by disabling the optimization normally done to
them. In other words, it causes the compiler to emit
larger, slower, but apparently correct, code.



Attachment: lua-5.1.4-no_logical_op_opt.patch
Description: Binary data