Richard Salz wrote:
double/triple check over it). Whatever fix you guys come up with, as
long
as SSL_shutdown() ends up having sane (somehow aligned to SSL_read,
SSL_write, etc...) semantics WRT non-blocking BIOs.
Nope. Maybe a new shutdown that has your semantics, but do not break
existing code.
Great lets do that then have a SSL_shutdown2() based on my patch.
Would Davide be so kind as to look over the following openssl-dev list
post for the semantics I suggest and confirm that logic would work for him:
http://marc.info/?l=openssl-dev&m=115153998821797&w=2
Maybe Davide could also try my PATCH2 and confirm that he can get sane
working non-blocking semantics with the new behavior. I think my patch
is easier all around and does not introduce this new WANT_SHUTDOWN
voodoo (which I think is unnecessary when I've been able to solve this
problem in a way inline with the way OpenSSL is).
I would also be surprised if my patch breaks existing code, since a
return value of -1 should be allowed to SSL_shutdown(), all I'm doing is
nailing down exactly what -1/WANT_WRITE, -1/WANT_READ, 0 and 1 return
codes mean in the context of a shutdown.
Yes its a change, yes its going to break someones code, so I'm more than
happy with having a new SSL_shutdown2() API call, if you consider this a
real compatibility issue.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
