qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
Date: Fri, 22 Jan 2010 14:17:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

malc <address@hidden> writes:

> On Thu, 21 Jan 2010, Jamie Lokier wrote:
>
>> 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.
>> 
>> > 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).
>> 
>
> My sentiment exactly.
>
> An example:
>
> Dinkum Unabridged Library was certified by Perennial 
> (http://peren.com/pages/aboutus_set.htm) to conform
> to ISO/IEC 9899:1999.
>
> Documentation for realloc:
> http://www.dinkumware.com/manuals/?manual=compleat&Search=realloc&page=stdlib.html#realloc
>
> Hallvard B Furuseth analysis fully applies i believe...

Regardless of whether his analysis applies to this implementation's
documentation or not: what does this implementation actually do?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]