Ralf S. Engelschall wrote:
>
> On Wed, Nov 18, 1998, Ben Laurie wrote:
>
> >[...]
> > > My $0.02, if it's worth anything. But if that's the way you code
> > > Apache-SSL, I'm very glad my friend pointed me to mod_ssl.
> >
> > If you want to use a system where programming errors are "corrected" by
> > removing the assertions that reveal them, that is your choice, of
> > course.
>
> Please be technical only and correct. The assertions were not just removed in
> mod_ssl. They were replaced with run-time checks which pass the error up to
> the callers and there it's handled without and exit().
I don't understand the distinction you are trying to draw. A fatal error
was made non-fatal when it should not have been.
> And IMHO the assertions
> were also not assertions for programming errors. Because why has asserting the
> returned number of bytes from read() anything to do with a programming error?
> It's just an I/O error.
We've been over this already, but once more: it isn't "just an I/O
error", its something that can only happen if something has gone wrong
with either Apache-SSL or gcache. The fact that this results in an I/O
error is no more relevant than if it resulted a segmentation fault or in
a variable being set to an impossible value. If an I/O error can occur
_without_ a bug in the code, and with some possibility of recovering
from it, then it would be appropriate to attempt to handle the error. As
far as I currently know, this is not the case.
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
