> > > In what way this break already used applications ???
> > > In what way this break anything ???
> [snip]
> > block. Fortunately for the original poster, he was able to detect this
> > problem and can now easily fix it by using non-blocking sockets. (And
> > with luck he won't make this same mistake with TCP, UDP, or any other
> > protocol. It bites more people more often than you might think. It's a
> > common issue on USENET.)
> This is getting scary.
> The original poster (that would be me) ran into the problem in s_client,
> part of OpenSSL.
I guess it comes down to whether the intention was to block until
application-level data could be received. If the OpenSSL authors don't know
that you *must* set a socket non-blocking to ensure that socket operations
don't block, that would be sad.
In any event, if there is a bug in s_client, good that we caught it. A
lot
of people use that code as an example and this might lead them to think that
you can 'select' following by blocking sockets operations and still somehow
be assured of not blocking. You cannot, and any code based on that
assumption is broken.
It's hard for me to imagine s_client could be broken that badly. I'll
take
a look at it.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
