From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MA5fB-0003Ir-Oy
	for qemu-devel@nongnu.org; Fri, 29 May 2009 13:14:37 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MA5f7-0003Gc-7M
	for qemu-devel@nongnu.org; Fri, 29 May 2009 13:14:37 -0400
Received: from [199.232.76.173] (port=40573 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MA5f7-0003GZ-0r
	for qemu-devel@nongnu.org; Fri, 29 May 2009 13:14:33 -0400
Received: from server1linux.rebelnetworks.com ([66.135.44.167]:35043)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <jseward@acm.org>) id 1MA5f6-0001yW-MF
	for qemu-devel@nongnu.org; Fri, 29 May 2009 13:14:32 -0400
From: Julian Seward <jseward@acm.org>
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 19:17:10 +0200
References: <200905290758.11551.jcd@tribudubois.net>
	<4A1FD6E2.9020006@redhat.com>
	<200905291407.26757.paul@codesourcery.com>
In-Reply-To: <200905291407.26757.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200905291917.10535.jseward@acm.org>
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: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Jean-Christophe Dubois <jcd@tribudubois.net>, Paul Brook <paul@codesourcery.com>, Gerd Hoffmann <kraxel@redhat.com>

On Friday 29 May 2009, Paul Brook wrote:
> >(e) return malloc(0), without wrapping it into oom_check().
>
> This is the worst of both worlds.
>
> > 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.
>
> The best way to find broken code is to have qemu_malloc(0) abort, and avoid
> ever trying to allocate a zero size block.

+1 for that.  Code that relies on malloc(0) doing any specific thing
is basically bad news when it comes to portability, robustness
and understandability.  Better to have qemu_malloc(0) abort, put up with
a couple of days of the trunk aborting, until these uses are fixed.
I'd be surprised if there were many cases anyway.

J