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 Tue, 21 May 2002 02:34:04 GMT
At 05:57 PM 5/20/2002, Greg Stein wrote:
>On Fri, May 17, 2002 at 02:38:27PM -0500, William A. Rowe, Jr. wrote:
> >...
> > > > > trawick     02/05/17 07:58:27
> > > > >
> > > > >   Modified:    strings  apr_cpystrn.c
> > > > >   Log:
> > > > >   don't check for malloc() failure in our strdup() replacement
> >...
> > 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.
>
>It will fail right off the bat as we memcpy() the old string into the new.
>So it will be quite obvious in this case :-)

Which is goodness, thanks for the observation!

> > 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.
>
>Here is a much simpler answer: simply nuke the strdup() replacement.
>
>Why do we need to supply strdup() ? We never use it. It isn't "our problem".
>We encourage people to use pools, not to use strdup() and other malloc-based
>APIs.

IIRC, str[n]dup[n] is certainly non-portable.  str[n]cpy[n] is equally 
non-portable,
due to the fact that it is so frequently misimplemented.

I don't think throwing out the baby with the bath water is necessarily the 
right
answer.  No great love for this fn, but I don't see axing it simply because
it doesn't fit in the pools model.

Bill



Mime
View raw message