From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MA1Mi-00054v-Lc
	for qemu-devel@nongnu.org; Fri, 29 May 2009 08:39:16 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MA1Md-0004vd-QH
	for qemu-devel@nongnu.org; Fri, 29 May 2009 08:39:16 -0400
Received: from [199.232.76.173] (port=37279 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MA1Md-0004vE-JG
	for qemu-devel@nongnu.org; Fri, 29 May 2009 08:39:11 -0400
Received: from mx2.redhat.com ([66.187.237.31]:54475)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MA1Md-0007Ml-5P
	for qemu-devel@nongnu.org; Fri, 29 May 2009 08:39:11 -0400
Message-ID: <4A1FD6E2.9020006@redhat.com>
Date: Fri, 29 May 2009 14:36:50 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] use qemu_malloc and friends consistently
References: <200905290758.11551.jcd@tribudubois.net>	<4A1F9FFE.3030100@redhat.com>
	<4A1FA573.4010602@codemonkey.ws>	<Pine.LNX.4.64.0905291335130.3397@linmac.oyster.ru>	<4A1FBEB2.2030009@codemonkey.ws>
	<Pine.LNX.4.64.0905291506340.3744@linmac.oyster.ru>
In-Reply-To: <Pine.LNX.4.64.0905291506340.3744@linmac.oyster.ru>
Content-Type: text/plain; charset=ISO-8859-1; 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: malc <av1474@comtv.ru>
Cc: Kevin Wolf <kwolf@redhat.com>, Jean-Christophe Dubois <jcd@tribudubois.net>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

> a. return NULL
> b. return malloc(1)
> c. abort
> d. do what OpenBSD does

(e) return malloc(0), without wrapping it into oom_check().

> In a nutshell what i argue is that, if someone doesn't need any memory
> it shouldn't be asking for it, and it's not that unlikely that the
> author never considered the possibility of his code requesting zero
> bytes of memory,

If the calling code correctly keeps track of the allocated amount of 
memory (which it should do anyway for correctness and security reasons) 
the zero-length case will not cause any hickups.  It will happily copy 
zero bytes, do zero loop interations, or whatever else.

Aborting on qemu_malloc(0) forces the call sites to add a special case 
for len=0, even though correctly written code doesn't need a special 
case for it.

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.

cheers,
   Gerd