Project

General

Profile

Actions

Bug #17857

closed

`when 0r` and `when 0i` do not match with `case 0`

Added by mame (Yusuke Endoh) almost 3 years ago. Updated almost 3 years ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:103791]

Description

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.


Related issues 1 (0 open1 closed)

Related to Ruby master - Bug #17854: Crash with certain "case" expressions on FreeBSDClosedshyouhei (Shyouhei Urabe)Actions
Actions #1

Updated by mame (Yusuke Endoh) almost 3 years ago

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

Updated by shyouhei (Shyouhei Urabe) almost 3 years ago

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

Updated by jeremyevans0 (Jeremy Evans) almost 3 years ago

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

Actions #4

Updated by jeremyevans (Jeremy Evans) almost 3 years ago

  • Status changed from Open to Closed

Applied in changeset git|9ce29c94d82c6bf278b1be088435726a9c47e225.


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

Fixes [Bug #17857]

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0