[ruby-core:41378] [ruby-trunk - Feature #5678] StringIO#to_str

Issue #5678 has been updated by Martin Bosslet.


Yukihiro Matsumoto wrote:
> Hi,
>  In message "Re: [ruby-core:41354] [ruby-trunk - Feature #5678][Closed] StringIO#to_str"
>      on Mon, 28 Nov 2011 18:50:12 +0900, Martin Bosslet <[e-mail]> writes:
>  
>  At the same time, having ASN1.decode to treat T_FILE but not StringIO
>  is against duck typing.  I think it is better if we can do something.
>  But I don't have a good idea yet.  #to_io does not work here. #to_str
>  is not appropriate.
>  
>  							matz.

We could handle StringIO exceptionally by trying to call #string on the
object passed. But that's not too elegant and will probably only work in
the very specific case of StringIO. Implementing #to_s like Nikolai
suggested could be another solution? Then we could apply the following 
heuristic that should cover almost any (valid) case:

1. check for T_FILE
2. try #to_str
3. try #to_s ?

----------------------------------------
Feature #5678: StringIO#to_str
http://redmine.ruby-lang.org/issues/5678

Author: Martin Bosslet
Status: Closed
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