Re: [Bug-gnulib] xmalloc and rpl_malloc

[Bruno Haible]

Paul Eggert writes:

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

That what I had in mind too.

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

The important rule is that if X is an array of N objects, and 0 <= i,j
<= N, then &X[i] == &X[j] if and only if i == j. How can this hold if
sizeof(X[0]) == 0 ?

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

The point is: If malloc is specified in the standard as returning
non-NULL for n==0 if there is memory available, then a previously
compliant program becomes noncompliant.

> Or did you mean that a C program might define malloc itself?  But that
> also violates the standard.

Huh?! All the provisions in the ELF runtime system, that guarantee
that a malloc() in the executable hides a malloc() in libc, their
purpose must be to fulfill a standard, isn't it?

Bruno