Re: [Qemu-devel] [PATCH] fix qemu_malloc() error check for size==0

[Jamie Lokier <jamie@shareable.org>]

Eduardo Habkost wrote:
> Excerpts from Jamie Lokier's message of Tue May 19 17:32:23 -0300 2009:
> > Eduardo Habkost wrote:
> > > Now, _that_ sounds like a really bad idea. realloc(NULL, n) is specified
> > > to be equivalent to malloc(n).
> > 
> > No it isn't.  You can't make that substitution.
> > 
> > In the case where n == 0, realloc(NULL, n) is guaranteed to not
> > allocate anything and return NULL, whereas malloc(n) does not
> > guarantee that and in fact doesn't do that on a lot of implementations.
> 
> http://opengroup.org/onlinepubs/007908775/xsh/realloc.html
> 
> "If ptr is a null pointer, realloc() behaves like malloc() for the
> specified size."
> 
> "If size is 0, either a null pointer or a unique pointer that can be
> successfully passed to free() is returned."

Oh.  Thanks!  I stand corrected; sorry for propagating misinformation.

The relevant part in the standard which makes the above not contradict
realloc's freeing behaviour, is "if size is 0 and __ptr is not a null
pointer__, the object pointed to is freed."

All this creates a different problem, unfortunately:

If you do:

    p = malloc(n)         /* Arbitrary n, could be zero. */
    free(p)

it works, but

    p = realloc(oldp, n)  /* Arbitrary n, could be zero. */
    realloc(p, 0)

is not guaranteed to free the allocated block, if n == 0 && p == NULL.

realloc(p, 0) is not equivalent to free(p) in this problem cases.

Which is IMHO another reason to either forbid n == 0, or warn about
it, or change it unambiguously to n == 1 in the qemu_ wrappers.

While we're here, the C language FAQ adds:

Q: Is it legal to pass a null pointer as the first argument to
    realloc? Why would you want to?

A: ANSI C sanctions this usage (and the related realloc(..., 0), which
   frees), although several earlier implementations do not support it, so
   it may not be fully portable.

-- Jamie