On 5/22/07, Kevin Reid <kpreid@...> wrote:
> On May 21, 2007, at 17:41, Erik Huelsmann wrote:
> > While looking through the sources of various sockets
> > implementations because of my work for usocket, I found a bug in sb-
> > bsd-sockets where connect() will fail if a connect is interrupted
> > or if the socket is non-blocking.
> I object to calling this a bug for the non-blocking case. The current
> interface is a direct mapping of the underlying system call, which is
> explicitly specified to "fail" with EINPROGRESS.
Well, as you point out, the mapping would have been exact iff the
error raised wouldn't have been generic, but specific (as is the error
(It's always bad practice to regard all 'error codes' as errors
though! It's better to view them as status codes.)
The other reason I'm calling this a bug is because none of the other
functions return an error on receipt of EINTR or EAGAIN.
> > I think the code for connect should look something like the patch
> > below. It changes the return of connect() to sometimes return T (in
> > case additional waiting - with select() or poll()) is required.
> > This should not be a problem, because this was an error condition
> > before.
> No: it will be a problem for code written to expect EINPROGRESS as
> transformed into a condition. While I personally agree this is a
> better interface, it is a potentially incompatible change (and I have
> code which would need to be tweaked to function as intended with it).
Ok. Point taken. I have no real opinion one way or the other, since
I'm not (yet) providing non-blocking sockets support in usocket. I was
investigating the possibility and saw that at least some change in
sb-bsd-sockets would greatly improve my ability to create a *thin*
> If this change is preferred, how about making the return value be the
> condition that would have been signaled, rather than T? It's still a
> boolean, and it will avoid hiding the value of errno.
> (A related, compatible improvement would be to define a condition
> class for EINPROGRESS.)
That's fine by me too; but I think - but I can't access SF ViewVC now
- still incompatible with the rest of the sb-bsd-sockets interface.