apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr/strings apr_cpystrn.c
Date Fri, 17 May 2002 19:38:27 GMT
At 10:27 AM 5/17/2002, you wrote:
>Ben Laurie <ben@algroup.co.uk> writes:
>
> > trawick@apache.org 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


Mime
View raw message