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 http://www.lua.org/bugs.html#5.1.4-3, which has been applied in Lua 5.2.0-alpha, fixes this case: Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, 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 Lua.org, 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. HTH, -Sean
Attachment:
lua-5.1.4-no_logical_op_opt.patch
Description: Binary data