Re: proper realloc(p,0) behavior?

[Paul Eggert]

On 03/25/2011 06:53 AM, Eric Blake wrote:
> +/* Change the size of an allocated block of memory P to N bytes, with
> +   error checking.  This version explicitly rejects non-NULL P
> +   combined with N of 0, since the GNU realloc semantics of freeing P
> +   and returning NULL interfere with the promise of x*alloc methods
> +   never returning NULL.  */

This doesn't sound right.  xrealloc shouldn't reject a
set of arguments that realloc accepts.

Also, it doesn't match the comments and other code in
the module.  The x*alloc methods by and large don't promise that
they return a non-NULL pointer.  What they promise, is that they
check for out-of-memory conditions, so that the caller doesn't
have to.

For example, xmalloc (0) always succeeds, no matter what;
it never invokes xalloc_die ().  If the underlying malloc (0)
returns NULL, xmalloc (0) returns NULL.  The caller can't dereference
the NULL, but that's OK, as the caller couldn't dereference any
non-NULL returned value either.

The situation for xrealloc (p, 0) should be similar to that
of xmalloc (0).

Now, perhaps we should think about changing the semantics, so that
the x*alloc methods always return non-NULL.  But does any application
require the changed semantics?  If not, I'd be leery about changing
them.