From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MA2FT-0006k3-EK
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:35:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MA2FO-0006ge-UH
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:35:51 -0400
Received: from [199.232.76.173] (port=44788 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MA2FO-0006gG-FM
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:35:46 -0400
Received: from srv-05.w4a.fr ([94.23.5.116]:43209 helo=mx1.w4a.fr)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jcd@tribudubois.net>) id 1MA2FO-0004td-1p
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:35:46 -0400
Date: Fri, 29 May 2009 14:35:40 +0100 (GMT+01:00)
From: jcd@tribudubois.net
Message-ID: <2743272.69361243604140018.JavaMail.root@srv-05.w4a.fr>
In-Reply-To: <28932640.69341243603994530.JavaMail.root@srv-05.w4a.fr>
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>, qemu-devel@nongnu.org

So even if malloc(0) is legal per se, is it really exepected there is that =
much code in qemu relying on it?

It seems not (and there is also some qemu code considering NULL as a failur=
e value regardless of the value of size parameter) and fixing the few place=
s where this could be expected (like qemu-io.c) should not be a lot of work=
. All these "special" cases should be detected fairly quickly.

JC

----- "Paul Brook" <paul@codesourcery.com> a =C3=A9crit :

> >(e) return malloc(0), without wrapping it into oom_check().
>=20
> This is the worst of both worlds.
>=20
> > For the purpose of finding broken code returning NULL is IMHO the
> best
> > option.  Although dereferencing NULL is undefined, in practice it
> will
> > segfault in most cases so the bugs shouldn't stay unnoticed for
> long.
>=20
> The best way to find broken code is to have qemu_malloc(0) abort, and
> avoid=20
> ever trying to allocate a zero size block. Returning NULL is liable to
>=20
> introduce extra bugs because code often attributes special meaning to
> NULL=20
> pointers. It also breaks pointer comparison.
>=20
> To some extent the answer to this question depends how much you trust
> your=20
> programmers. If you assume everyone knows the C standard well and
> always=20
> writes perfect code then malloc(0) is a legitimate technique, though
> IMHO of=20
> fairly limited benefit.
>=20
> If you want maximize chances of catching accidental mistakes as early
> as=20
> possible then you should have malloc(0) abort, because it probably
> means=20
> someone forgot tho consider the empty case.
>=20
> Paul