Bug #1686
Enumerable#first broken
| Status: | Closed | Start date: | 06/25/2009 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | - | % Done: | 100% |
|
| Category: | core | |||
| Target version: | 1.9.2 | |||
| ruby -v: | ruby 1.9.2dev (2009-06-24 trunk 23840) [i386-darwin9.7.0] |
Description
Enumerable#first is broken in the current HEAD. If 4 <= n < enum_length + 4, enum.first(n) returns the (n-4)th element instead of an array of n elements. E.g.: to6 = (1..6).to_enum # necessary so Enumerable#first is used p to6.first(2) # ==> [1, 2] p to6.first(4) # ==> 1 p to6.first(9) # ==> 6 p to6.first(10) # ==> [1, 2, 3, 4, 5, 6] This is due to http://redmine.ruby-lang.org/repositories/diff/ruby-19/enum.c?rev=23622 , after which ary[0] holds "n" as a long instead of a Fixnum. The comparison to Qnil isn't working as desired. Either ary[0] holds INT2NUM(len) and first_i calls NUM2LONG + INT2NUM (as per my original patch, see http://redmine.ruby-lang.org/issues/show/1554 ) or alternatively, enum_first could use take_i or enum_take when there is an argument, since they behave the same way in that case.
Associated revisions
* enum.c (first_i): wrong condition for no argument #first.
[ruby-core:24017]
History
Updated by Yukihiro Matsumoto over 2 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Applied in changeset r23846.