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

[malc]

On Fri, 22 Jan 2010, Markus Armbruster wrote:

> 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".

It says, btw for some reason you've snipped the last part of the paragraph
in one of you previous posts:

      Returns

       [#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 if the new object  could  not |
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       be allocated.
       ^^^^^^^^^^^^^

^^ marks what you've snipped and under this GLIBC's behaviour is in
error, since

a. GLIBC returns NULL, which is only sanctioned if the new object
   is not allocated

b. From a) and #4 follows that the old object wasn't freed

>
> 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".

And the answer is "yes" if one follows simple logic.

> 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".

We really have to wait for TC.

[..snip..]

>
> 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 :)
>

-- 
mailto:address@hidden