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

[malc]

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 (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)?

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]

-- 
mailto:address@hidden