Bug #17857: `when 0r` and `when 0i` do not match with `case 0`

• Status: Closed
• Assignee: -
• Target version: -
• Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN

[mame (Yusuke Endoh)]

The following code prints :bar between Ruby 2.1 .. 2.5, and dumps core since Ruby 2.6.

case 0
when 0r
  p :foo
else
  p :bar #=> :bar
end

A Complex has the same issue.

case 0
when 0i
  p :foo
else
  p :bar #=> :bar
end

The segfault issue was fixed by #17854. So the current master it prints :bar.

However, I believe it should print :foo because 0r === 0 evaluates to true. This weird behavior is caused by the optimization which uses a hidden hash to dispatch to when clauses. By disabling the optimization, the code prints :foo.

opt = RubyVM::InstructionSequence.compile_option
opt[:specialized_instruction] = false
RubyVM::InstructionSequence.compile(<<END, **opt).eval
case 0
when 0r
  p :foo #=> :foo
else
  p :bar
end
END

I think the optimization should be disabled when T_RATIONAL or T_COMPLEX are used.

[mame (Yusuke Endoh)]

• Related to Bug #17854: Crash with certain "case" expressions on FreeBSD added

[shyouhei (Shyouhei Urabe)]

I agree. Optimisation that changes the behaviour of the program is not an optimisation. It's simply broken.

[jeremyevans0 (Jeremy Evans)]

I've submitted a pull request to fix this: https://github.com/ruby/ruby/pull/4496

• Status changed from Open to Closed

Applied in changeset git|9ce29c94d82c6bf278b1be088435726a9c47e225.

---

Avoid improper optimization of case statements mixed integer/rational/complex

Fixes [Bug #17857]