Re: [Bug-gnulib] xmalloc and rpl_malloc

[Paul Eggert]

Bruno Haible <address@hidden> writes:

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

Yes, that's the idea.

Perhaps we should put zmalloc, zcalloc, and zrealloc into a separate
include file zalloc.h?

>   - It's not so easy to get something accepted in standard commitees,

True, but it's easier if someone in the committee already wants it....

>   - Noone really needs zero-sized objects, the same way as, say,
>     'bool' and 'restrict' were needed,

Nobody really _needed_ bool either; they could just use 1 and 0.

>   - I can't imagine how these zero-sized objects could interfere
>     with the pointer comparison operator in a pleasant way,

If X is an array of N objects, and Y is another object, then it is
already the case that &X[N] == Y might yield 1 (and also, it might not
yield 1).  Presumably, this same rule will still hold if N == 0.


>   - 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; }

I don't follow this point.  The current standard does not specify that
malloc(0) must equal NULL.  Any program that requires that malloc(0)
must yield NULL is already nonconforming.  Changing the standard to
require that malloc(0) must yield non-NULL won't break any portable
programs.

Or did you mean that a C program might define malloc itself?  But that
also violates the standard.  A strictly conforming C program cannot
redefine any of the standard functions.