Bug #17014: Range#minmax returns incorrect results on non-numeric exclusive ranges

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: 2.7.1
• Backport: 2.5: DONTNEED, 2.6: DONTNEED, 2.7: DONE

[sambostock (Sam Bostock)]

The implementation of Range#minmax added in d5c60214c45 causes the following incorrect behaviour:

('a'...'c').minmax # => ["a", ["a", "b"]]

instead of

('a'...'c').minmax # => ["a", "b"]

Cause

This is because the C implementation of Range#minmax (range_minmax) directly delegates to the C implementation of Range#min (range_min) and Range#max (range_max), without changing the execution context.

Range#max's C implementation (range_max), when given a non-numeric exclusive range, delegates to super, which is meant to call Enumerable#max. However, because range_max is called directly by range_minmax, super calls Enumerable#minmax instead, causing the incorrect nesting.

Resolution

• ruby/ruby#3285 fixed this bug by explicitly calling Range#min and Range#max, instead of delegating directly to range_min and range_max
• ruby/ruby#3286 followed up by replacing rb_intern("min") and rb_intern("max") in the new implementation with statics id_min and id_max
• ruby/ruby#3290 follows up by extracting range_min_internal and range_max_internal from range_min and range_max, and calling those directly from range_minmax

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed
• Backport changed from 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN to 2.5: UNKNOWN, 2.6: REQUIRED, 2.7: REQUIRED

[jeremyevans0 (Jeremy Evans)]

• Backport changed from 2.5: UNKNOWN, 2.6: REQUIRED, 2.7: REQUIRED to 2.5: DONTNEED, 2.6: DONTNEED, 2.7: REQUIRED

[nagachika (Tomoyuki Chikanaga)]

• Backport changed from 2.5: DONTNEED, 2.6: DONTNEED, 2.7: REQUIRED to 2.5: DONTNEED, 2.6: DONTNEED, 2.7: DONE

ruby_2_7 d24cce8e7f48b0b45f726f5f1ac7ff796f46ba72 merged revision(s) bf1a6771f305ea286a3ae575676924551c03e857,c1463625555b061a2b94c3b6c5581730b482a285.