From: Rob Muhlestein <rmuhlestein@...>
Date: 2006-12-30T00:50:05+09:00
Subject: Re: unsafe readline(), anything better?

On Fri, 29 Dec 2006 10:19:52 +0100, Robert Klemme wrote:

> On 28.12.2006 22:09, Rob Muhlestein wrote:
>> I do love that Ruby let's me add to IO itself, which handles adding
>> @prev_read buffer to store the overrun in for next read and is what I'll
>> do and post for review.
> 
> I would also consider the alternative of creating a SafeLineReader that
> can be stacked on *any* IO object (or rather any object that implements
> #read with the proper protocol) as input stream much the same way Java
> streams can be stacked.  You gain flexibility but of course you loose the
> easy "I just need to open a file and it works".  I do not have a clear
> bias either way because I love the simplicity of Ruby's IO classes but on
> the other hand you can also stuff too much into a single class.

Glad to read your post. Couldn't sleep last night thinking through
this. Then this morning found that vulnerability in WEBrick based
on unsafe readlines (actually gets, but same deal). [see WEBrick DOS
Security Flaw thread]

The more I got into adding to IO the more I kept coming back to stack
design that you mention and that I'm familiar with. Mostly there are
a lot of methods in the IO and StringIO classes that would all have to
have equivalents that support the prev_read buffer. Also we face the
default duplex nature of IO and this is only for reads. So I do really
think stacking (the reader) stream is the way to go--especially with
support for things like '<<' in Ruby, which I love.

Maybe we could call it SafeReader so we can have its readline calling
a read_until (like I've done in other langs). In my few remaining
vacation hours, I'll try to write up a spec, perhaps in Rspec and post
for comment.

I'm still somewhat new to this Ruby stuff, but think I can get a gem
started on RubyForge for it, it would be my first. Then if there is enough
demand, we can implement one in C. By the way, anyone know of any gem
naming conventions to distinguish a pure Ruby gem from C extension
version, like Perl's XS suffix convention?

Also on a related topic, is there a convention or other reliable way to
avoid gem library directory and file name collisions? I did notice, for
example, webrick follows the webrick.rb and webrick/ convention as does
rspec and others. Are these names somehow registered publicly to avoid gem
collisions with others? Perhaps Brian or Ryan would care to set us newbies
straight on that. [I did do quite a bit of homework reading
http://rubygems.org particularly section 8. Distributing Gems]

-- 
Rob Muhlestein
http://rob.muhlestein.net