qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>
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	[thread overview]
Message-ID: <20100121182033.GD28467@shareable.org> (raw)
In-Reply-To: <m38wbr8i5k.fsf@blackfin.pond.sub.org>

Markus Armbruster wrote:
> malc <av1474@comtv.ru> 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

  parent reply	other threads:[~2010-01-21 18:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20091228134949.GC4908@volta.aurel32.net>
     [not found] ` <20091228145325.GA7139@shareable.org>
     [not found]   ` <Pine.LNX.4.64.0912282058310.2142@linmac.oyster.ru>
     [not found]     ` <20091229165007.GB18379@shareable.org>
     [not found]       ` <Pine.LNX.4.64.0912292316340.2155@linmac.oyster.ru>
2010-01-21 17:47         ` [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present Markus Armbruster
2010-01-21 18:04           ` malc
2010-01-21 18:45             ` Markus Armbruster
2010-01-21 19:04               ` malc
2010-01-22 13:16                 ` Markus Armbruster
2010-01-22 19:02                   ` malc
2010-01-21 18:20           ` Jamie Lokier [this message]
2010-01-21 18:26             ` malc
2010-01-22 13:17               ` Markus Armbruster
2010-01-22 18:54                 ` malc
2010-01-21 18:44             ` Markus Armbruster
2010-01-22  2:05               ` Jamie Lokier
2010-01-22 11:05                 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100121182033.GD28467@shareable.org \
    --to=jamie@shareable.org \
    --cc=armbru@redhat.com \
    --cc=aurelien@aurel32.net \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).