Re: [Bug-gnulib] xmalloc and rpl_malloc

[Bruno Haible]

Paul Eggert writes:
> 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.

I wouldn't bet on this because:
  - It's not so easy to get something accepted in standard commitees,
  - Noone really needs zero-sized objects, the same way as, say,
    'bool' and 'restrict' were needed,
  - I can't imagine how these zero-sized objects could interfere
    with the pointer comparison operator in a pleasant way,
  - Requiring that malloc(0) returns a non-null pointer would change
    some valid ISO C programs to invalid:

       char memory[100000];
       char *memptr = memory;
       void *malloc (size_t n) {
         return (n == 0 ? NULL : (memptr += n) - n);
       }
       int main () { if (malloc (0) != NULL) abort (); return 0; }

> 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.

Yes, I like this approach too. It makes things explicit, and avoids
the dangers of putting code which assumes  malloc == zmalloc  into
packages that don't call AC_FUNC_MALLOC.

The migration will be not so tough because we use xmalloc, not malloc,
in most places anyway.

Bruno