From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MA1o9-0001se-DA
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:07:38 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MA1o4-0001p8-Fo
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:07:36 -0400
Received: from [199.232.76.173] (port=58531 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MA1o4-0001ow-7l
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:07:32 -0400
Received: from mx20.gnu.org ([199.232.41.8]:7675)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1MA1o3-0007Bp-R2
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:07:31 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1MA1o2-00084S-3o
	for qemu-devel@nongnu.org; Fri, 29 May 2009 09:07:30 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
Date: Fri, 29 May 2009 14:07:25 +0100
References: <200905290758.11551.jcd@tribudubois.net>
	<Pine.LNX.4.64.0905291506340.3744@linmac.oyster.ru>
	<4A1FD6E2.9020006@redhat.com>
In-Reply-To: <4A1FD6E2.9020006@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200905291407.26757.paul@codesourcery.com>
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>, Gerd Hoffmann <kraxel@redhat.com>, Jean-Christophe Dubois <jcd@tribudubois.net>

>(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. Returning NULL is liable to 
introduce extra bugs because code often attributes special meaning to NULL 
pointers. It also breaks pointer comparison.

To some extent the answer to this question depends how much you trust your 
programmers. If you assume everyone knows the C standard well and always 
writes perfect code then malloc(0) is a legitimate technique, though IMHO of 
fairly limited benefit.

If you want maximize chances of catching accidental mistakes as early as 
possible then you should have malloc(0) abort, because it probably means 
someone forgot tho consider the empty case.

Paul