Re: [Bug-gnulib] xmalloc and rpl_malloc

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> I generally argue that the modules malloc and realloc shouldn't be
> used: they add a performance penalty to programs for the sake of
> using a nonstandard calling convention for two standard functions.

One could argue that they are merely giving you the preview of what
the next standard will (or should) look like.  The C Standard
committee will probably revisit this issue if/when they allow
zero-sized objects (this is a project of Doug Gwyn, who is on the
committee), and quite possibly they will change the spec for malloc to
behave the way that rpl_malloc currently behaves.

However, I agree that it is confusing that "malloc" in gnulib doesn't
mean the currently-standard "malloc".  We should use a different name
(perhaps "zmalloc"?) for a malloc that does the desired thing with
zero-sized requests.  zmalloc could be defined to be equivalent to
malloc on hosts where malloc already does the desired thing.  If the
standard is eventually revised so that zmalloc == malloc, we can
eventually remove zmalloc (probably 20 or 30 years from now).

I like the idea of decoupling xmalloc.c from malloc.c, but I don't
like the duplication of function in the proposed patch, and I also
don't like using #if to enclose sequences of tokens that are not
statements or declarations.

So, how about a different solution instead, along these lines?
It's a bit more drastic, but it results in cleaner code.

   1.  In config.h, define MALLOC_0_IS_NONNULL to 1 if malloc (0) is
       known to return nonnull, 0 otherwise.

   2.  Define a new function zmalloc as follows, in xalloc.h:

         static inline void *
         zmalloc (size_t n)
         {
           return malloc (MALLOC_0_IS_NONNULL || n ? n : 1);
         }

   3.  Use zmalloc instead of malloc whenever the difference matters,
       e.g. in xmalloc's function body.

   4.  Remove malloc.c and rpl_malloc.  Do not #define malloc.

   5.  Similarly for realloc and calloc.