Project

General

Profile

Actions

Bug #2380

closed

IO#eof? behavior different with 1.9.1p243-mingw32 than other platforms

Added by undees (Ian Dees) over 14 years ago. Updated almost 13 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]
Backport:
[ruby-core:26788]

Description

=begin
In the following code:

open('somefile.txt', 'r') do |f|
until f.eof? do
raise 'nil character' if f.getc.nil?
end
end

The code runs without error in both Ruby 1.8 and 1.9 on Ubuntu, and 1.8 on Win32. The call to eof? returns true and prevents getc from being called in a situation that would return nil. But Ruby 1.9 on Win32 throws the "nil character" exception shown.

This difference disrupts tools like autospec, which opens a pipe to a subprocess and reads the results character by character.

Luis Lavena offers the following observations after his own tests of the issue:

"I just tested exact same example with 1.8.6 without errors (somefile containing both LF or CRLF).... I can confirm this fails with 1.9.1 patchelvel 243, but works with patchlevel 129, which indicates a regression in Ruby."
=end


Related issues 1 (0 open1 closed)

Is duplicate of Backport191 - Backport #2168: File.eof? does not work correctlyClosedyugui (Yuki Sonoda)10/01/2009Actions
Actions #1

Updated by usa (Usaku NAKAMURA) over 14 years ago

  • Status changed from Open to Assigned
  • Assignee set to usa (Usaku NAKAMURA)

=begin

=end

Actions #2

Updated by vvs (Vladimir Sizikov) over 14 years ago

=begin
Actually, I see it on 1.9.1 pl129 and earlier 1.9.1 builds as well, and not only mingw, bun mswin32 as well. And looking at the (git mirror of) MRI repo, there were no IO changes between 129 and 243, so the regression is done sometime earlier than that. It is clearly reproducible with files that have "windows" CRLF format. Also, opening them in binary "rb" mode eliminates the problem. So it definitely looks like CRLF-thing.

Here's the run against the versions I have (and did I mention that pik totally rocks for such tasks?):

pik ruby eof_t.rb

ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]

ruby 1.8.6 (2009-08-04 patchlevel 383) [i386-mingw32]

ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-cygwin]

ruby 1.8.7 (2009-06-12 patchlevel 174) [i386-mswin32]

ruby 1.9.0 (2008-06-20 revision 17482) [i386-mswin32]

ruby 1.9.1p0 (2009-01-30 revision 21907) [i386-mswin32]
eof_t.rb:3:in block in <main>': nil character (RuntimeError) from eof_t.rb:1:in open'
from eof_t.rb:1:in `'

ruby 1.9.1p0 (2009-01-30 revision 21907) [x64-mswin64_80]
eof_t.rb:3:in block in <main>': nil character (RuntimeError) from eof_t.rb:1:in open'
from eof_t.rb:1:in `'

ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-mswin32]
eof_t.rb:3:in block in <main>': nil character (RuntimeError) from eof_t.rb:1:in open'
from eof_t.rb:1:in `'

ruby 1.9.2dev (2009-07-18) [i386-mswin32]
eof_t.rb:3:in block in <main>': nil character (RuntimeError) from eof_t.rb:1:in open'
from eof_t.rb:1:in `'

ruby 1.9.2dev (2009-11-12 trunk 25723) [i386-mingw32]
eof_t.rb:3:in block in <main>': nil character (RuntimeError) from eof_t.rb:1:in open'
from eof_t.rb:1:in `'

=end

Actions #3

Updated by vo.x (Vit Ondruch) over 14 years ago

=begin
This error duplicates [Bug #2168] I would say
=end

Actions #4

Updated by usa (Usaku NAKAMURA) over 14 years ago

=begin
Hello,

In message "[ruby-core:26800] [Bug #2380] IO#eof? behavior different with 1.9.1p243-mingw32 than other platforms"
on Nov.18,2009 17:36:35, wrote:

This error duplicates [Bug #2168] I would say

I've confirmed that they are the same problem.

Regards,

U.Nakamura

=end

Actions #5

Updated by usa (Usaku NAKAMURA) over 14 years ago

  • Status changed from Assigned to Open
  • Assignee deleted (usa (Usaku NAKAMURA))

=begin

=end

Actions #6

Updated by luislavena (Luis Lavena) over 14 years ago

=begin
On Thu, Nov 19, 2009 at 9:05 PM, Tanaka Akira wrote:

It seems that (current) universal newline is not what
windows people want.

Pardon my ignorance on this matter, but is beyond my knowledge why
Ruby perform a huge amount of magic in relation to newlines for
Windows, while others languages just play "as is" with it, adding
special notes in the documentation for users to avoid falling into
these traps.

Of course, the only place that magic is being used is to read source
lines and useful to display the proper line number on errors

Indeed I'm missing something, but all the magic around newlines for
Ruby slowed down file reading and writing performance to the point of
making it useless on Windows.

--
Luis Lavena
AREA 17

Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

=end

Actions #7

Updated by akr (Akira Tanaka) over 14 years ago

  • Status changed from Open to Closed

=begin
This issue was solved with changeset r25883.
Vit, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0