Bug #14974: "if" statement executes wrong branch

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[kratob (Tobias Kraze)]

I've stumbled over a rather weird bug where Ruby 2.5+ executes an else branch of a condition when it should not. The best minimal example I could come up with is this:

def broken
  foo = 1
  if is_true or is_false
    foo = foo
  else
    raise "FAIL"
  end
  puts "PASS"
end

def is_true
  true
end

def is_false
  false
end

broken()

For me this script raises "FAIL" instead of printing "PASS".

Note that this is actually pretty much minimal; any of the following will "fix" the issue:

• inlining is_true or is_false
• removing the foo = foo or adding any other code to the if branch
• replacing raise "FAIL" with puts "FAIL"
• removing the puts "PASS"

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed

This appears to be a duplicate of #14897.

[mame (Yusuke Endoh)]

jeremyevans0 (Jeremy Evans) wrote:

This appears to be a duplicate of #14897.

Yes, it is already fixed in trunk. Please wait for the next release. Anyway, thank you for the report!

OT: I'm surprised that multiple persons encounter this issue because it occurs only when a nonsense assignment like foo = foo is used.

[znz (Kazuhiro NISHIYAMA)]

• Related to Bug #14897: Unexpected behavior of `if` in specific code added

[shevegen (Robert A. Heiler)]

occurs only when a nonsense assignment like foo = foo is used.

Could happen because of a typo or the brain-associated with the
fingers in some thought process. I made very strange mistakes
myself; most common one I still make is "=" rather than "=="
simply because I somehow forget to type == (hit = twice). Happens
perhaps 1 in 1000 times only when I am very alert but when I
am quite sleepy it may be 1 in 100 times.

What I mean to say is that we can expect the unexpected as a
result of humans working with computers in general. :)