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
