Re: proper realloc(p,0) behavior?

[Eric Blake]

On 03/25/2011 10:07 AM, Paul Eggert wrote:
> On 03/24/2011 04:52 PM, Bruno Haible wrote:
>>   Leaking memory when you are already out of memory is not a problem: the
>>   program will need to terminate very soon anyway. So code which calls
>>   realloc(p,0) and does not free p if that returns NULL is just fine.
> 
> I hadn't thought of this argument, and it's a good one; thanks.
> 
> Come to think of it, I don't know of any implementation where,
> if P is nonnull, then realloc (P, 0) can return NULL without
> freeing P.

C99 _requires_ that if realloc (P, 0) returns NULL, then P was _not_
freed.  On the Austin Group meeting, the Oracle representative stated
that the Solaris 11 implementation of realloc() will likely be changed
to _not_ free P if realloc returns NULL (that is, change from behavior b
[GNU semantics] over to behavior a/c [C99 semantics] in Bruno's
summary).  And BSD implementations are already in behavior a/c.

http://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00252.html

where realloc (P,0) returns a non-NULL result (P is freed, and a
zero-size object allocated - but then you are likely to leak the
zero-size object if you don't check for NULL but just assume GNU
semantics), or leaves P allocated if it returns NULL (P is not freed
because you can't even allocate a zero-size object - but that's the OOM
case).

>  So even though C99 allows such behavior in theory,

Not just allows, but requires.

> are we worrying about a memory-leak issue that is only theoretical?

The problem is not GNU semantics in isolation or C99 semantics in isolation.

If you _know_ that you have GNU semantics, then you also _know_ that
realloc(p,0) freed p and returned NULL without you having to check the
return value (it did _not_ try to allocate a zero-size object, so there
was no way for the allocation to fail, so you can't detect an OOM
situation, but you also know that P was freed).

If you _know_ that you have C99 semantics, then you also _know_ that
realloc(p,0) requires you to check the return value, at which point
either the return value is non-NULL (p was freed _and_ you have a
non-NULL pointer in its place that you must later free) or NULL (p was
_not_ freed because you could not allocate a zero-sized object - either
this is because you are OOM on a system where malloc(0) normally returns
non-NULL, or it is because you are on a system like AIX where malloc(0
also returns NULL so you can never request a zero-sized object).

The problems occur when you mix implementations with assumptions.

If you _assume_ GNU but have C99, then you likely failed to check the
return value of realloc(p,0) because you _assumed_ it just freed p and
returned NULL; but since C99 says that either it returned NULL and did
not free p, or did not return NULL and you have a new pointer to free,
you have a leak.  How likely is this bug to hit in real life?  I don't
know, because I haven't yet finished a systemtap script to probe how
many programs in Linux trigger realloc(p,0) in my typical workflow.  But
Jim found only autoconf tests and one candidate program in his google
code search.  And how severe are such memory leaks?  It's hard to say,
but they usually don't lead to crashes unless there are a _lot_ of
realloc(p,0) going on in a program.

If you _assume_ C99 but have GNU, then you have an even worse bug - you
will check the return value of realloc(p,0) and see that it is NULL, so
you assume that p is still valid, and you must later call free(p).  But
because realloc already freed p, you have a double free.

Assuming GNU semantics means that we'll never hit the double-free bug
but might have a memory leak, whereas assuming C99 semantics is much
more likely to crash on non-C99 systems.  Therefore, I argue that the
GNU semantics are saner, but not that they are perfect.

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

signature.asc
Description: OpenPGP digital signature