[Firstly, I'm working with 0.9.5a, but the relevant 0.9.6 source seems to be
unchanged.]
This may be a bigger problem than just my specific case, but here is what
I've found:
We are using BIO_do_handshake() to accept socket connections, which results
in a call to BIO_accept(). Calling BIO_accept() on a non-blocking socket
with no connections pending results in a fatal error on Win32, but not on
other platforms. The reason for this difference seems to be in the
processing of BIO_sock_should_retry(). This function contains:
#if defined(WINDOWS) && 0 /* more microsoft stupidity? perhaps not? Ben
4/1/99 */
if ((i == -1) && (err == 0))
return(1);
#endif
In the case that I'm witnessing, the above if-statement evaluates to true.
So, if the "&& 0" in the #ifdef is removed, the Win32 behaviour is the same
as on other platforms. Should the "&& 0" be removed?
However, the correct solution may be more specific. At the time that accept
fails, WSAGetLastError() returns WSAEWOULDBLOCK. By the time that
BIO_sock_should_retry() is called, WSAGetLastError() returns 0, which I
guess is why the above code was added in the first place. Obviously some
Win32 call, or socket call, between the accept, and the
BIO_sock_should_retry() is resetting the error code.
Any suggestions for the correct way to rectify this situation?
Steven
--
Steven Reddie <[EMAIL PROTECTED]>
Senior Software Engineer
OpenDirectory Lab, Computer Associates Pty Ltd (Australia)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
