On Wed, Nov 18, 1998, Ben Laurie wrote:
> > 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.
Yes, your position is based on the assumption that an I/O _cannot_ occur. And
I don't want to assume this, so I check for those I/O errors explicitly.
Actually not really a point of discussion, more a point of programming style.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
Apache Interface to SSLeay (mod_ssl) www.engelschall.com/sw/mod_ssl/
Official Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
