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:
>> malc <address@hidden> writes:
>> 
>> > On Tue, 29 Dec 2009, Jamie Lokier wrote:
>> >
>> >> malc wrote:
>> >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
>> >> > 
>> >> > > Aurelien Jarno wrote:
>> >> > > > This fixes the loading of a stripped kernel with zero malloc 
>> >> > > > disabled.
>> >> > > 
>> >> > > *Raises an eyebrow*
>> >> > > 
>> >> > > Even though there's different perspectives over whether qemu_malloc(0)
>> >> > > should be allowed, inherited from ambiguity over malloc(0),
>> >> > > realloc(p,0) has always had a standard, well-defined meaning.
>> >> > 
>> >> > No.
>> >> > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b
>> >> 
>> >> Wow, thanks for that.  It's a real surprise.  Looks like C99's own
>> >> rationale is not consistent with itself on the subject, and differs
>> >> from C90 where the "standard, well-defined meaning" I referred to was
>> >> defined.
>> >
>> > Yep.
>> 
>> No, this is a misinterpretation of the C99 standard, made possible by
>> its poor wording.  The C99 Rationale is perfectly clear, though:
>> 
>>     7.20.3.4 The realloc function
>> 
>>     A null first argument is permissible.  If the first argument is not
>>     null, and the second argument is 0, then the call frees the memory
>>     pointed to by the first argument, and a null argument may be
>>     returned; [...]
>
> The rationale above does not match C89 behaviour.  It says the call
> frees the memory, but it does not forbid the call from then proceeding
> to do the same as malloc(0) and return a non-NULL pointer.  It's quite
> explicit: a null argument *may* be returned.  Which means the
> rationale does not require realloc(p,0) to do the same as C89, which
> always frees the memory and doesn't allocate anything.

I didn't claim there's *no* difference between C89 and C99.  In fact,
the Rationale nicely documents the change:

    A new feature of C99: the realloc function was changed to make it
    clear that the pointed-to object is deallocated, a new object is
    allocated, and the content of the new object is the same as that of
    the old object up to the lesser of the two sizes.  C89 attempted to
    specify that the new object was the same object as the old object
    but might have a different address.  This conflicts with other parts
    of the Standard that assume that the address of an object is
    constant during its lifetime.  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).

>> This is hardly surprising, because anything else would break working C89
>> programs, and that would squarely contradict the standard's mission,
>
> Understood.  But it doesn't really matter what's intended or what's
> misinterpreted.  If there are any significant implementations out
> there based on the "misinterpretation", or even based on the
> rationale, that's enough of a reason to not depend on realloc(p,0).

There are none.

I don't really care how scared QEMU is of realloc(p, 0).  I just want to
correct the misinformation on the standard being spread on this list.