RPM Community Forums

Mailing List Message of <popt-devel>

Re: Question about the xmalloc() et al functions

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 10 Mar 2008 - 00:26:31 CET
Message-Id: <CF3B12F8-B6AC-40CE-BAE9-F122D10AF730@mac.com>

On Mar 9, 2008, at 7:13 PM, Wayne Davison wrote:

> I'm curious why the xmalloc() function (and its brethren) exits with a
> fatal error on only some systems and not on all systems?  I would  
> think
> that the code should use the exiting functions in all cases, and just
> provide differing versions of xstrdup() so that the HAVE_MCHECK_H
> version does a malloc() (rather than strdup() doing it).
>

xmalloc() et al is mostly a fetish of mine.

I personally believe that its silly wasting time checking _ALL_
code paths for malloc failures. 99.999% of the time returning
an error rather than aborting is pointless anyways (imho).

> If I'm not off track, you can apply the attached patch to implement
> this.
>

There are some subtleties however with xstrdup. If strdup(3), rather  
than
what I use with rpm
     #define xstrdup(_str)   (strcpy((malloc(strlen(_str)+1) ? :  
vmefail(strlen(_str)+1)), (_str)))
is done, then line numbers reported by glibc mtrace(3) will be wrto  
strdup,
not the caller of strdup.

All that stops me from using everywhere is the GNU extension that is  
needed by
xstrdup so that the xstrdup macro is mostly side-effect free (I don't  
care so
much that the (_str) macro argument is used several times on the  
error paths,
its used only once on the success paths.

And sure a static inline function avoids all the side-effects, but  
static inline functions
were unknown to me last century when the hackery was first devised.  
valgrind
dinna exist, and Rational Purify cost the Very Big $$$ back then too ...

73 de Jeff
Received on Mon Mar 10 00:26:41 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.