[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] xmalloc and rpl_malloc
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] xmalloc and rpl_malloc |
Date: |
Wed, 15 Jan 2003 13:52:27 +0100 (CET) |
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