bug-gnulib
[Top][All Lists]
Advanced

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

Re: proper realloc(p,0) behavior?


From: Eric Blake
Subject: Re: proper realloc(p,0) behavior?
Date: Fri, 25 Mar 2011 10:31:27 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9

On 03/25/2011 09:59 AM, Paul Eggert wrote:
> 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.

Fair enough.  But we _still_ need to fix the regression you introduced
yesterday.

realloc(NULL, 0) is an uncontroversial case to request the same behavior
as malloc(0).  (The controversy is only over a non-null pointer argument).

GNU malloc(0) always allocates a zero-size object, therefore, so does
GNU realloc(NULL, 0).  But your patch yesterday makes it end up
returning NULL instead of a zero-size object.

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

True enough.  But if you are using the gnulib malloc-gnu module, then
you are guaranteed that malloc(0) never returns NULL, and therefore that
xmalloc(0) never returns NULL.

And I have written code that assumes that xmalloc() never returns NULL.

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

Most of my code that uses xmalloc in an assumption where it never fails
is malloc-ing non-zero sizes.  That is, I rarely use zero-size objects.

So off hand, I don't have a good example of code that does xmalloc()
where the size argument could be 0, to prove whether the subsequent code
depended on a non-NULL result.

My personal opinion is that xalloc(0) should guarantee GNU semantics, as
should xrealloc(NULL, 0), in returning a zero-size object even if the
underlying malloc(0) returns NULL.

But looking again at xmalloc.c, I do indeed see that xmalloc(0) will
return NULL if malloc(0) has not been replaced by the malloc-gnu module
to guarantee a non-NULL result.  So you have convinced me that
xrealloc(p, 0) may safely return NULL; however, I still think that
xrealloc(NULL,0) _must_ return malloc(0) rather than blindly returning NULL.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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