Actions
Bug #17014
closedRange#minmax returns incorrect results on non-numeric exclusive ranges
Bug #17014: Range#minmax returns incorrect results on non-numeric exclusive ranges
Description
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#minandRange#max, instead of delegating directly torange_minandrange_max - ruby/ruby#3286 followed up by replacing
rb_intern("min")andrb_intern("max")in the new implementation with staticsid_minandid_max - ruby/ruby#3290 follows up by extracting
range_min_internalandrange_max_internalfromrange_minandrange_max, and calling those directly fromrange_minmax
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- 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
Updated by jeremyevans0 (Jeremy Evans) over 5 years ago
- Backport changed from 2.5: UNKNOWN, 2.6: REQUIRED, 2.7: REQUIRED to 2.5: DONTNEED, 2.6: DONTNEED, 2.7: REQUIRED
Updated by nagachika (Tomoyuki Chikanaga) over 5 years ago
- 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.
Actions