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

[Markus Armbruster]

malc <address@hidden> writes:

> On Thu, 21 Jan 2010, Markus Armbruster wrote:
>
>> malc <address@hidden> writes:
>> 
>> > On Thu, 21 Jan 2010, Markus Armbruster wrote:
>
> [..snip..]
>
>> >> No, this is a misinterpretation of the C99 standard, made possible by
>> >> its poor wording.  The C99 Rationale is perfectly clear, though:
>> >
>> > You have to show the flaw in Hallvard B Furuseth's analysis to claim
>> > that it's a misinterpretation. And unlike the standard rationale is
>> > non normative.
>> >
>> > [..snip..]
>> 
>> I did.  If that doesn't convince you, I'll gladly wait for the Technical
>> Corrigendum that'll put this rather absurd misreading to rest.
>
> If you did, then, i guess, i've missed it, here's the whole analysis,
> please point what and where is wrong:
>
> [quote: 
> http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b]
>
> C90 said realloc(non-null, 0) did free().  C99 inverted that, saying it
> does not:
>
> The only place where 7.20.3.4 (The realloc function) mentions that
> realloc may free the old object, is in the case where it returns another
> object.

7.20.3.4 starts with the simple, unconditional statement:

    The realloc function deallocates the old object pointed to by ptr
    and returns a pointer to a new object that has the size specified by
    size.

The only place where it limits this clause is here:

    If memory for the new object cannot be allocated, the old object is
    not deallocated and its value is unchanged.

Therefore, saying that realloc() frees the old object only when "it
returns another object" is imprecise.  What the standard *actually* says
is realloc() frees unless "the new object cannot be allocated".

The question is whether returning null for a zero-sized allocation is to
be considered "the new object cannot be allocated".  The claim that
realloc(p, 0) may not free(p) relies on the answer to that question
being "yes".

However, the Rationale maintains that the answer is "no".  Which is
consistent with the previous iteration of the standard, common usage
predating the standard, and thus with the standard's mission to avoid
"quiet changes".

>          7.20.3 (Memory management functions) says zero-sized allocation
> returns NULL, but 7.20.3.4 overrides that.
>
> Could we have the original behavior back, please?  I've seen people say
> the current definition is unintentional.  And it conflicts with the C99
> Rationale:
>
>    7.20.3.4 The realloc function
>
>    (...)  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,
>
> though that goes on with
>
>    and a null argument may be returned; C99 is consistent with the
>    policy of not allowing zero-sized objects.
>
> Is that supposed to mean no new object is returned but the return value
> is indeterminate, or does it mean that it might free the old object and
> return an inaccessible new object like malloc(0)?

It means it must free the old object and may return either null or an
inaccessible new object, just like malloc(0).

The "policy of not allowing zero-sized objects" refers back to 7.20.3:

    Some implementations have returned non-null values for allocation
    requests of zero bytes.  Although this strategy has the theoretical
    advantage of distinguishing between "nothing" and "zero" (an
    unallocated pointer vs. a pointer to zero-length space), it has the
    more compelling theoretical disadvantage of requiring the concept of
    a zero-length object.  Since such objects cannot be declared, the
    only way they could come into existence would be through such
    allocation requests.

    The C89 Committee decided not to accept the idea of zero-length
    objects.  The allocation functions may therefore return a null
    pointer for an allocation request of zero bytes.  Note that this
    treatment does not preclude the paradigm outlined above.

> Repeating from old realloc(non-null, 0) discussions:
>
> In the latter case a program which sees a NULL return from
> realloc(non-null, 0) cannot know if the old object was freed or not -
> i.e. it cannot know if the NULL was a failure return (from allocating
> the new object) or a success return (after freeing the old object).
>
> Which is exactly the situation for a portable program which sees such a
> NULL return today - it cannot know if it was a C99 failure return or a
> C90 success return.  Even if the language is C99, the library might be
> C90. 
>
> [end quote]

If your reading of the standard leads to conclusions like "breaks most
existing programs in an unfixable way", in absence of any evidence of
such breakage in practice, then it's maybe time to double-check it
against the Rationale.

If C99 made the sky fall, we'd be done being crushed by now :)