From: "brixen (Brian Ford)" <brixen@...>
Date: 2012-10-27T12:28:01+09:00
Subject: [ruby-core:48443] [ruby-trunk - Feature #7220] Separate IO#dup, StringIO#initialize_copy from dup(2)


Issue #7220 has been updated by brixen (Brian Ford).


drbrain (Eric Hodel) wrote:
> This is intentional behavior which has existed since 1998. It is not a bug.
> 
> When I am working with IOs I expect the ruby methods to follow POSIX conventions more than ruby conventions. This method is not the only one in the standard library that doesn't follow ruby conventions.
> 
> If you wish to change this behavior you must demonstrate the change will be harmless and easy for existing libraries to adapt to. I don't believe this is the case (due to the drastic change in behavior this would introduce), or that such a change is worthwhile after nearly 15 years.


The time it has been implemented is a ridiculous standard. So is requiring it to be easy to adapt to. Nothing that has changed in 1.9 has respected such a standard.

There are serious problems with aliasing the same fd as IO#dup does. It is not consistent across platforms. At the very least, the implementation leaves huge holes, like allowing one fd to be closed, and that IO's #closed? will return true, but the aliasing IO's #closed? will return false, and closing it will raise Errno::EBADF. That behavior shouldn't be behind a common Ruby method or concept.

Further, if StringIO is supposed to mimic all this, there are numerous bugs because StringIO instances that are aliases via #dup do report the same value for eg closed?.

I'm not asking to remove the ability to use dup(2) but that it not be hidden behind Ruby's concept of #dup. I am certain that most Ruby developers understand nothing of the complexities of aliasing a system resource like an fd between different Ruby objects because I've fixed tons of EBADF bugs is RubySpec due to IO#dup. MRI very likely has no tests for such problems.

----------------------------------------
Feature #7220: Separate IO#dup, StringIO#initialize_copy from dup(2)
https://bugs.ruby-lang.org/issues/7220#change-31770

Author: brixen (Brian Ford)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: Next Major


Calling StringIO#initialize_copy causes the two objects to share the position, and eof status.

Is this a bug?

sasha:rubinius brian$ irb
1.9.3p286 :001 > require 'stringio'
 => true 
1.9.3p286 :002 > a = StringIO.new "abcdefuq"
 => #<StringIO:0x00000101016a88> 
1.9.3p286 :003 > b = StringIO.new
 => #<StringIO:0x00000101010728> 
1.9.3p286 :004 > b.send :initialize_copy, a
 => #<StringIO:0x00000101010728> 
1.9.3p286 :005 > a.pos
 => 0 
1.9.3p286 :006 > b.pos
 => 0 
1.9.3p286 :007 > b.getc
 => "a" 
1.9.3p286 :008 > a.pos
 => 1 
1.9.3p286 :009 > a.getc
 => "b" 
1.9.3p286 :010 > b.pos
 => 2 
1.9.3p286 :011 > b.read
 => "cdefuq" 
1.9.3p286 :012 > a.eof?
 => true 

Thanks,
Brian


-- 
http://bugs.ruby-lang.org/