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: Fri, 22 Jan 2010 02:05:40 +0000	[thread overview]
Message-ID: <20100122020540.GA5601@shareable.org> (raw)
In-Reply-To: <m3ockn47si.fsf@blackfin.pond.sub.org>

Markus Armbruster wrote:
> I didn't claim there's *no* difference between C89 and C99.  In fact,
> the Rationale nicely documents the change:
> 
>     [snipped]
>     Also, implementations that support an
>     actual allocation when the size is zero do not necessarily return a
>     null pointer for this case.  C89 appeared to require a null return
>     value, and the Committee felt that this was too restrictive.
> 
> So C99 permits realloc(p, 0) to return a non-null value.  Regardless, it
> still *requires* it to free(p).

Nobody disagrees that it does free(p).

The question is whether it may _follow_ the free(p) with malloc(0) and
return that, in which case the returned pointer must eventually be
passed to a subsequent free() to avoid leaks, or if it only doess
free(p) and a non-null result must be ignored.

For either meaning of non-null result, there are valid C89 programs which
will break, either leaking or calling free() on an invalid address.

> I just want to correct the misinformation on the standard being
> spread on this list.

I can't tell from your writing which misinformation you mean.

The only thing in question is the (new in C99) possibility of non-null
result and what to do with one (that it does free(p) is not in doubt),
and I'm afriad the sections you quoted firmly support the non-null
result change, and perpetuate the ambiguity of it's meaning.

In any case, there is no doubt, from the possibiliy of non-null result
alone (which is clear), that is already enough to make some valid C89
code misbehave.

The ambiguity of a non-null result (i.e. whether it is equivalent to
malloc(0) and the caller must free it later, or it is something the
caller must ignore because the realloc(p,0) call is equivalent to
free(p) only) is what makes it seem unsafe to call realloc(p,0) at all.

I don't want to argue and I really appreciate your clarification if
you know something.  If there is misinformation, it would be good to
correct it, in which case I don't think you have succeeded.

Unfortunately I can't tell from your mail what you think the meaning
of a non-null result is.

-- Jamie

  reply	other threads:[~2010-01-22  2:06 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
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 [this message]
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=20100122020540.GA5601@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).