Issue #5678 has been updated by Martin Bosslet.


Nobuyoshi Nakada wrote:
> Martin Bosslet wrote:
> > The following raises an error currently:
> > 
> >   require 'stringio'
> >   require 'openssl'
> > 
> >   io = StringIO.new(OpenSSL::ASN1::Integer.new(1).to_der)
> >   asn = OpenSSL::ASN1.decode io
> 
> Why do you need to pass `io', not io.string or the result of to_der?

I don't really need to, it's just that I am working on making 
ASN1.decode streaming-aware. So I wanted it to work with any 
IO or IO-like object and additionally with Strings. That's why 
I thought if someone passes a StringIO, they would be surprised
if an error was raised - they passed an IO-like object after all
and there is no apparent reason why this shouldn't work.

I could, however, call StringIO#string as you suggested, but
I would prefer to use StringValue, as a more generic way
of coercing things into Strings. And it would potentially work
for a wider variety of objects, not only limited to StringIO. 

Do you see any negative aspects when adding StringIO#to_str? 
----------------------------------------
Feature #5678: StringIO#to_str
http://redmine.ruby-lang.org/issues/5678

Author: Martin Bosslet
Status: Feedback
Priority: Normal
Assignee: Nobuyoshi Nakada
Category: ext
Target version: 2.0.0


The following raises an error currently:

  require 'stringio'
  require 'openssl'

  io = StringIO.new(OpenSSL::ASN1::Integer.new(1).to_der)
  asn = OpenSSL::ASN1.decode io

The reason is that ossl_obj2bio[1] looks for a
T_FILE first, and then it tries to coerce the
input to a String using StringValue. StringValue
itself again expects the presence of to_str,
which is currently missing for StringIO, but
could be easily provided by aliasing 
StringIO#string. 

I could imagine that the heuristic of ossl_obj2bio
is quite common when working on binary data in a
C extension. Would it therefore be OK to add 
StringIO#to_str? Patch attached.


[1] https://github.com/ruby/ruby/blob/trunk/ext/openssl/ossl_bio.c#L17


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