On Thu, 31 Mar 2005 15:37:21 +0200, Sander Striker <[EMAIL PROTECTED]> wrote: > Ryan Bloom wrote:
> > If the documentation says what is > > macro, then that is almost guaranteed to be out of date at some point > > in the future. And, what happens when sometimes it is a function and > > sometimes it is a macro, depending on the compiler used or what > > #defines are set? > > It's a function when pool debugging is enabled. Both the function and > the macro will be present, so linking is always possible. This was > one of the requirements since we didn't want to inconvenience developers > switching between debug/release builds. > > The argument that the code segfaults when apr_palloc isn't able to > allocate any memory is moot. Dean and others have indicated more > than once that memory allocators usually do lazy allocation, which > would result in segfaults in the code anyway because malloc never > returns NULL. > > Given that, we could even opt for removing the abort callback function > altogether. No, we couldn't opt for removing the abort callback. The reason that was added, is that it isn't valid for a library to seg fault or just abort in most situations. The abort callback was added because HTTPd wanted to just kill the child process ASAP. Other applications may want to try to print an error message in this case, so that the user or developer can try to figure out what went wrong. We can't gaurantee that the app will survive the call to abort, but we need to at least attempt to give other applications the chance to behave differently from HTTPd. Ryan -- Ryan Bloom [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
