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