From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9zox-0006E6-5p for qemu-devel@nongnu.org; Fri, 29 May 2009 07:00:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9zor-00069H-AK for qemu-devel@nongnu.org; Fri, 29 May 2009 07:00:18 -0400 Received: from [199.232.76.173] (port=60336 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9zoq-000692-SQ for qemu-devel@nongnu.org; Fri, 29 May 2009 07:00:13 -0400 Received: from mx2.redhat.com ([66.187.237.31]:59922) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9zoq-0002UW-BB for qemu-devel@nongnu.org; Fri, 29 May 2009 07:00:12 -0400 Message-ID: <4A1FBFAE.3020004@redhat.com> Date: Fri, 29 May 2009 12:57:50 +0200 From: Gerd Hoffmann 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Kevin Wolf , Jean-Christophe Dubois , Paul Brook , qemu-devel@nongnu.org On 05/29/09 11:51, malc wrote: >> Having qemu_malloc(0) abort is silly. Returning NULL or returning >> malloc(1) are both reasonable options. > > Dereference of NULL is UB[1] and dereferencing result of malloc(1) will > just plain work. malloc(0) itself isn't a bug. Dereferencing the pointer is. Code like this: buf = qemu_malloc(len); memcpy(buf, src, len); will work perfectly fine when called with len=0 because it will not dereference buf for the len=0 case. abort() in qemu_malloc for size=0 will fire for no good reason. > P.S. So far the abort that went into qemu_malloc caught one usage of zero > allocation (once again coming from qcow2). That was a false positive. cheers, Gerd