Skip to content

StringIO#puts with nil prints "nil" not "" #2113

ashmoran opened this Issue Jan 2, 2013 · 4 comments

2 participants

ashmoran commented Jan 2, 2013

(I just added this as a comment to #550 which looks similar, but that didn't re-open it so I've made a new one. Copied and pasted…)

I just ran into the following behaviour and I'm not sure if it's (a) a bug and (b) the same behaviour described in this ticket.

If you run the following spec file:

describe StringIO do
  let(:output_io) { }
  def output

  specify {
    expect(output).to be == ""

in MRI 1.9.3, you get the following output:

✗ rvm 1.9.3 exec rspec io_puts_nil_spec.rb

but in Rubinius (rubinius 2.0.0rc1 (1.9.3 release 2012-11-02 JI) [x86_64-apple-darwin12.2.0]):

✗ rvm rbx exec rspec io_puts_nil_spec.rb


  1) StringIO 
     Failure/Error: expect(output).to be == ""
       expected: == ""
            got:    "nil"
     # ./io_puts_nil_spec.rb:12:in `__script__'
     # kernel/common/eval19.rb:45:in `instance_eval'
     # kernel/bootstrap/array19.rb:18:in `map'
     # kernel/bootstrap/array19.rb:18:in `map'
     # kernel/loader.rb:697:in `run_at_exits'
     # kernel/loader.rb:717:in `epilogue'
     # kernel/loader.rb:850:in `main'

Finished in 0.01265 seconds
1 example, 1 failure

Can anyone confirm the correct behaviour and if this is related to this ticket or is a separate issue.

Rubinius member
dbussink commented Jan 4, 2013

Looks like StringIO hasn't been changed in 1.9 mode for this behavior:

ashmoran commented Jan 4, 2013

I notice that says this:

if arg.nil?
  line = "nil"

but says this:

if arg.equal? nil
  str = ""

Two questions:

  • Why do these check for nilness differently?
  • The methods are almost identical, can the duplication be removed?

I'd be happy to have a go at fixing and/or refactoring this if I knew what I was doing. I'm very new to Rubinius.

Rubinius member
dbussink commented Jan 9, 2013

The checks are different probably because they have been changed for 1.9 mode for IO, but haven't changed for StringIO yet.

Regarding the duplication, this is always a tricky point. The problem is that within Rubinius we aren't as free to refactor stuff like this because people expect certain classes to behave in certain ways and have certain hierarchies. So in this case moving this to a module would mean introducing that concept into IO. It's the safest approach to keep the duplication here and just fix StringIO.

Rubinius member

Closing this one, since it was fixed with pull request #2129

@dbussink dbussink closed this Jan 23, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.