[boost] Re: (Another) socket streams library

From: pedro.lamarao_at_[hidden]
Date: 2005-04-22 10:17:04

Caleb Epstein wrote:
> https://mndfck.org/svn/socketstream/trunk/example/time/session.h
> 
> Buffer overflow here:
> 
> 			char s[3];
> 			this->time(s);
> 
> where ::time indexes s[0..3].  There's even a comment:
> 
> // assume we really got a string of the appropriate size

Yeah, that should be a 4. Thanks.

> Overall this seems like a nice implementation of blocking,
> iostream-able socket classes and related plumbing.  I know different
> folks are looking for different things in a network library.  The
> example programs are all well written (modulo that bug above) and
> concise, which is a tribute to the your implementation.  At the same
> time, it is missing  asynchronous and/or non-blocking operations and
> any means for doing single-threaded I/O multiplexing (e.g.
> select/poll/etc).
> 
> If non-blocking I/O were a possibility, I don't think throwing
> exceptions on EWOUDBLOCK would be performant.

I don't think it is necessary to throw an exception from the stream to
signal it, for the same reason the stream can signal other kinds of
errors without throwing exceptions. The standard basic_ios base class is
even nice enough to offer the exceptions(iostate) "property" for you to
choose if you want or don't want exceptions to be thrown. Nothing new here.

I believe a non-blocking mode is possible for std::iostream, but I'm
unsure of how... elegant would it be to use it.

But should we offer the possibility for the user to set socket options,
or merely offer a blocking(bool) method?

Also, how should the stream object behave in case of EWOULDBLOCK? Set
failbit? Even if we use a wouldblockbit, we still need to set failbit,
as the only thing clear is that the operation was *not* successful.

Then, what would the programmer need to check if the code gets to the else?

protocol_message m;
if (stream >> m) {
} else {
        // what is the cause of the failure?
}

That'll probably need one or two more if's to test all the status bits.
It's ugly, and I hope there's some other, more interesting, way.

--
 Pedro Lamarão