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: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present
Date: Thu, 21 Jan 2010 18:20:33 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

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

-- Jamie




reply via email to

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