On Sat, 7 Jul 2001, Justin Erenkrantz wrote: > On Sat, Jul 07, 2001 at 04:01:35PM -0700, dean gaudet wrote: > > what's it really matter? trying to clean up from OOM is near impossible.
It doesn't matter if it's impossible or not. The problem is that we are in a library, so we can't just write to stderr by default. You have no way of knowing what stderr is, or that it even exists. > Which brings me back to my original question: "Why do we have an abort > function?" As you said (I was originally thinking this, but admittedly, > I didn't bring this up), we can't do much. About the only thing we can > do is exit. We *might* be able to make a log entry somewhere, but that > depends if we need memory to do the printf or whatnot. The point is that the original code from Apache 1.3 wrote a message to stderr, and aborted. The new code, has that option, but the default is to return an error condition to the caller. Again, you can't just write to stderr, because you don't know that stderr even exists anymore. > And, if palloc returns junk - NULL or non-NULL, we're bound to segfault > at some point - which takes care of our process anyway. Error-checking > is something that we pointedly avoid doing in APR. > > I'm not still sure what the abort function gets us. -- justin The simple ability to let the program decide how to handle this error condition. This was pain-stakingly decided over a year ago, and before we decide to take it out, please go back and read the mailing list archives for November 1999. Apache wants to write an error message and abort. I will -1 having a general purpose library do that by default, because it is VERY inconsiderate to the calling program. A general purpose library must allow the program to know what is going on before it just dies. I don't care if 99% of the time it is impossible to recover. This isn't about recovery. It is about not allowing the library to just kill the program. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
