From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MB6Zg-00030o-BB
	for qemu-devel@nongnu.org; Mon, 01 Jun 2009 08:25:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MB6Zb-0002yA-EN
	for qemu-devel@nongnu.org; Mon, 01 Jun 2009 08:25:07 -0400
Received: from [199.232.76.173] (port=39406 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MB6Zb-0002y1-3M
	for qemu-devel@nongnu.org; Mon, 01 Jun 2009 08:25:03 -0400
Received: from srv-05.w4a.fr ([94.23.5.116]:42286 helo=mx1.w4a.fr)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jcd@tribudubois.net>) id 1MB6Za-0007L1-Dm
	for qemu-devel@nongnu.org; Mon, 01 Jun 2009 08:25:02 -0400
Date: Mon, 1 Jun 2009 13:24:53 +0100 (GMT+01:00)
From: jcd@tribudubois.net
Message-ID: <1318873.71811243859093306.JavaMail.root@srv-05.w4a.fr>
In-Reply-To: <1758936.71791243858884274.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: Jamie Lokier <jamie@shareable.org>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org


----- "Jamie Lokier" <jamie@shareable.org> a =C3=A9crit :

> jcd@tribudubois.net wrote:
> > Hi Kevin,
> >=20
> > Thanks for pointing this. I guess it just sounds strange to me that
> > somebody would want to alloc 0 bytes. But why not ...
>=20
> Something that nobody pointed out is that sometimes you can have
> zero-length structures these days.  E.g. if you have a struct
> containing a few spinlocks in the Linux kernel, it will be zero
> length
> when built on UP targets.  I doubt if QEMU has any such structures,
> but it's the sort of thing that shouldn't break
> qemu_malloc(sizeof(some_type)).

This is true but the kernel API is also making a clear distinction between =
the NULL returned value for allocation error and the specific ZERO_SIZE_PTR=
 value returned for kmalloc(0, XXX). Things don't get mixed ...

JC

> -- Jamie