From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NHhSK-0004Ix-Bo
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:33:04 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NHhSE-0004Cb-6M
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:33:02 -0500
Received: from [199.232.76.173] (port=60834 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NHhSD-0004CD-UP
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:32:58 -0500
Received: from mail-px0-f171.google.com ([209.85.216.171]:52759)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <glommer@gmail.com>) id 1NHhSD-00064L-CH
	for qemu-devel@nongnu.org; Mon, 07 Dec 2009 12:32:58 -0500
Received: by pxi1 with SMTP id 1so3159339pxi.29
	for <qemu-devel@nongnu.org>; Mon, 07 Dec 2009 09:32:55 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <4B1A9811.8020108@codemonkey.ws>
References: <m3skbwxgkp.fsf@crossbow.pond.sub.org>
	<4B193DA5.6040507@codemonkey.ws> <4B1A9359.8080305@redhat.com>
	<4B1A9811.8020108@codemonkey.ws>
Date: Mon, 7 Dec 2009 15:32:54 -0200
Message-ID: <5d6222a80912070932t6c3b1cfew1f2232173524ddfa@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
From: Glauber Costa <glommer@gmail.com>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>

> So the only correct way would be to write:
>
> array =3D malloc(size);
> if (array =3D=3D NULL && size !=3D 0) {
> =C2=A0 return -ENOMEM;
> }
>

Of course we can differentiate. A failed malloc will abort, a successful on=
e
will not.

> If you were writing portable code. =C2=A0But that's not what people write=
. =C2=A0You
> can argue that qemu_malloc() can have any semantics we want and while tha=
t's
> true, it doesn't change my above statement. =C2=A0I think the main argume=
nt for
> this behavior in qemu is that people are used to using this idiom with
> malloc() but it's a non-portable practice.
>
> If qemu_malloc() didn't carry the name "malloc()" then semantics with siz=
e=3D0
> would be a different discussion. =C2=A0But so far, all qemu_* functions t=
end to
> behave almost exactly like their C counterparts. =C2=A0Relying on the res=
ult of
> size=3D0 with malloc() is broken.

We can change qemu_malloc to qemu_alloc_memory(), or whatever.
But from the moment we do things like abort on failing, we are already
deviating from its C counterpart.

--=20
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."