At 10:27 AM 5/17/2002, you wrote:
Ben Laurie <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> >
> > trawick 02/05/17 07:58:27
> >
> > Modified: strings apr_cpystrn.c
> > Log:
> > don't check for malloc() failure in our strdup() replacement
>
> Errrr - why not?
we're going to get segfaults inside strdup() anyway on some platforms
because we'll segfault when the OS fails to find a free page when we
try to write to it
we're going to get segfaults in the caller of such an allocation
routine because we don't check the retval religously
if there isn't enough storage to satisfy the strdup() it is a broken
environment anyway, and why should we waste the pathlength for the
other 99.9% of the users so that we can possibly trade one symptom of
a broken environment for another?
We have an callback for pool functions, often set to NULL, but none the less
we need to check or the segfault may occur in a less than obvious point.
I'm not sure how the pool malloc failure callback works into this, or any other
non-pool function. Perhaps we need a global malloc failure callback?
We simply don't need to check the results of apr_fooalloc because this callback
must have handled the condition.
Bill
