[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proper realloc(p,0) behavior?

From: Paul Eggert
Subject: Re: proper realloc(p,0) behavior?
Date: Fri, 25 Mar 2011 08:59:51 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]