From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NGypd-0008Qo-8x
	for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:54:09 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NGypY-0008M7-Jh
	for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:54:08 -0500
Received: from [199.232.76.173] (port=47951 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NGypY-0008Lo-BN
	for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:54:04 -0500
Received: from mail-yx0-f188.google.com ([209.85.210.188]:34426)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1NGypY-0001P4-Ap
	for qemu-devel@nongnu.org; Sat, 05 Dec 2009 12:54:04 -0500
Received: by yxe26 with SMTP id 26so3096132yxe.4
	for <qemu-devel@nongnu.org>; Sat, 05 Dec 2009 09:54:03 -0800 (PST)
Message-ID: <4B1A9E39.2030602@codemonkey.ws>
Date: Sat, 05 Dec 2009 11:54:01 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
References: <m3skbwxgkp.fsf@crossbow.pond.sub.org>	<4B193DA5.6040507@codemonkey.ws>
	<4B1A9359.8080305@redhat.com> <4B1A9811.8020108@codemonkey.ws>
	<4B1A9AF9.8000107@redhat.com>
In-Reply-To: <4B1A9AF9.8000107@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Avi Kivity <avi@redhat.com>
Cc: qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>, Markus Armbruster <armbru@redhat.com>

Avi Kivity wrote:
> A zero-supporting qemu_malloc() is fully compatible with malloc(), 
> we're only restricting the possible returns.  So we're not misleading 
> any caller.  In fact, taking your argument to the extreme, a malloc 
> implementation would need to

This is really the crux of the whole argument.  You're arguing that 
while most people rely on incorrect idioms with malloc(), the problem is 
not the idioms themselves but the definition of malloc().  The opposing 
argument is that instead of providing a "fixed" version of malloc(), we 
should encourage people to use a proper idiom.

I dislike the entire notion of qemu_malloc().  I've always disliked the 
fact that it abort()s on OOM.  I'd rather see us use a normal malloc() 
and code to that malloc currently which means avoiding size=0 and 
checking NULL results.

However, this is all personal preference and I'd rather focus my energy 
on things that have true functional impact.  Markus raised a valid 
functional problem with the current implementation and I proposed a 
solution that would address that functional problem.  I'd rather see the 
discussion focus on the merits of that solution than revisiting whether 
ANSI got the semantics of malloc() correct in the standards definition.

Regards,

Anthony Liguori