Bug #15600: CSV underlying IO object is not getting rewound after parsing

• Status: Third Party's Issue
• Assignee: -
• Target version: -
• ruby -v: ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin16]
• Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN

[chi (Chi Leung)]

Hello,

Sorry if this bug has already been reported but I couldn't find any reference to it.

For the following CSV test.csv file:

a,b,c,d
1,2,3,4
5,6,7,8
9,10,11,12

and the following code snippet:

require 'csv'
csv = ::CSV.open('./test.csv', {headers: true, col_sep: ','})
p csv.eof?
csv.readline
p csv.eof?
csv.readline
p csv.eof?
csv.readline
p csv.eof?

I got the following results with 2.6.1:

false
true
true
true

but using ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin16] I got:

false
false
false
true

It might be an intentional behaviour but in that case, I can't see anything in the documentation explicitly saying that we shouldn't rely on the underlying IO object to know the state of the current CSV object (as it was possible in the previous minor version) and couldn't find the related changelog.

Thanks for your work.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Third Party's Issue

It might be an intentional behaviour but in that case, I can't see anything in the documentation explicitly saying that we shouldn't rely on the underlying IO object to know the state of the current CSV object (as it was possible in the previous minor version) and couldn't find the related changelog.

You can report this to the upstream of CSV.
I guess it has never guaranteed such assumption, though.

[chi (Chi Leung)]

Hi nobu, thanks for your reply.

I guess it has never guaranteed such assumption, though.

Sorry, what I meant is that I don't understand why #eof? would be part of the CSV object public API if it doesn't reflect the state of the current object anymore and was never meant to do.

I will raise a ticket on the upstream repository.