Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present

[Markus Armbruster]

Jamie Lokier <address@hidden> writes:

> Markus Armbruster wrote:
>> I didn't claim there's *no* difference between C89 and C99.  In fact,
>> the Rationale nicely documents the change:
>> 
>>     [snipped]
>>     Also, implementations that support an
>>     actual allocation when the size is zero do not necessarily return a
>>     null pointer for this case.  C89 appeared to require a null return
>>     value, and the Committee felt that this was too restrictive.
>> 
>> So C99 permits realloc(p, 0) to return a non-null value.  Regardless, it
>> still *requires* it to free(p).
>
> Nobody disagrees that it does free(p).

Apparently malc does.

> The question is whether it may _follow_ the free(p) with malloc(0) and
> return that, in which case the returned pointer must eventually be
> passed to a subsequent free() to avoid leaks, or if it only doess
> free(p) and a non-null result must be ignored.
>
> For either meaning of non-null result, there are valid C89 programs which
> will break, either leaking or calling free() on an invalid address.
>
>> I just want to correct the misinformation on the standard being
>> spread on this list.
>
> I can't tell from your writing which misinformation you mean.

I mean the claim that realloc(p, 0) does not always free(p).

> The only thing in question is the (new in C99) possibility of non-null
> result and what to do with one (that it does free(p) is not in doubt),
> and I'm afriad the sections you quoted firmly support the non-null
> result change, and perpetuate the ambiguity of it's meaning.
>
> In any case, there is no doubt, from the possibiliy of non-null result
> alone (which is clear), that is already enough to make some valid C89
> code misbehave.
>
> The ambiguity of a non-null result (i.e. whether it is equivalent to
> malloc(0) and the caller must free it later, or it is something the
> caller must ignore because the realloc(p,0) call is equivalent to
> free(p) only) is what makes it seem unsafe to call realloc(p,0) at all.
>
> I don't want to argue and I really appreciate your clarification if
> you know something.  If there is misinformation, it would be good to
> correct it, in which case I don't think you have succeeded.
>
> Unfortunately I can't tell from your mail what you think the meaning
> of a non-null result is.

There is really nothing special about a non-null value returned by
realloc(p, 0).  Quoting C99 7.20.3.4:

    The realloc function returns a pointer to the new object (which may
    have the same value as a pointer to the old object), or a null
    pointer [...]

So this is really the same deal as with malloc():

* If you get a non-null value, you should pass it to free() to avoid
  memory leaks (actually, you may pass any value you get to free, since
  free() does nothing for null arguments).

* Checking for failure is tricky, because size argument zero may get you
  a null value.

There is no "ambiguity of a non-null result".

You are right on C99 breaking programs that assumed realloc(p, 0)
*always* returned null.  Quoting the C99 Rationale (emphasis mine):

    Also, implementations that support an actual allocation when the
    size is zero do not necessarily return a null pointer for this case.
    C89 *appeared* to require a null return value, and the Committee
    felt that this was too restrictive.

And this is where C89 7.10.3.4 appears to require it, but in fact
doesn't:

    Description
    [...]
    If ptr is a null pointer, the realloc function behaves like the
    malloc function for the specified size.  Otherwise, if ptr does not
    match a pointer earlier returned by the calloc, malloc, or realloc
    function, or if the space has been deallocated by a call to the free
    or realloc function, the behavior is undefined.  If the space cannot
    be allocated, the object pointed to by ptr is unchanged.  If size is
    zero and ptr is not a null pointer, the object it points to is
    freed.

The last sentence specifies only that the old object is freed.  It
doesn't specify return of a null value.  The return value is covered by
the *next* section:

    Returns

    The realloc function returns either a null pointer or a a pointer to
    the possibly moved allocated space.

For C99, the committee made the fact that realloc(p, 0) need not return
null explicit.  Unfortunately, they messed up the wording, which has led
a few people to believe the spec for realloc() changed incompatibly in
C99.  It did not.

Anything still unclear?


The practical question is of course whether realloc(p, 0) can be used
safely in portable programs.  It can, in the same way it's always been
used:

* If it yields a non-null value, you pass it to free()

* If it yields a null value, this means "out of memory" only if you
  asked for a non-zero size.

Note that such a portable program doesn't need to know how the
implementation defines behavior for zero arguments.