From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MA73q-0005kv-A0
	for qemu-devel@nongnu.org; Fri, 29 May 2009 14:44:10 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MA73k-0005j3-U4
	for qemu-devel@nongnu.org; Fri, 29 May 2009 14:44:09 -0400
Received: from [199.232.76.173] (port=60177 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MA73k-0005iy-IB
	for qemu-devel@nongnu.org; Fri, 29 May 2009 14:44:04 -0400
Received: from mx2.redhat.com ([66.187.237.31]:49142)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MA73k-0008GZ-2X
	for qemu-devel@nongnu.org; Fri, 29 May 2009 14:44:04 -0400
Message-ID: <4A202C71.7090506@redhat.com>
Date: Fri, 29 May 2009 20:41:53 +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>
	<4A1FD6E2.9020006@redhat.com>
	<200905291407.26757.paul@codesourcery.com>
	<200905291917.10535.jseward@acm.org>
In-Reply-To: <200905291917.10535.jseward@acm.org>
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: Julian Seward <jseward@acm.org>
Cc: Kevin Wolf <kwolf@redhat.com>, Jean-Christophe Dubois <jcd@tribudubois.net>, qemu-devel@nongnu.org, Paul Brook <paul@codesourcery.com>

On 05/29/09 19:17, Julian Seward wrote:
> On Friday 29 May 2009, Paul Brook wrote:
>> 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.

The *only* thing you can rely on is that the value returned by malloc(0) 
can be passed to free() without trouble.

Code like this ...

   buf = malloc(len);
   for (i = 0; i < len; i++)
      do_something_with(buf[i]);
   free(buf);

... works perfectly fine for len=0, no matter how malloc(0) is actually 
implemented because buf is never ever dereferenced then.

With the current qemu_malloc() implementation it will abort instead and 
you'll have to add extra code to make len=0 a special case for IMO no 
good reason.

> Better to have qemu_malloc(0) abort, put up with
> a couple of days of the trunk aborting, until these uses are fixed.

Oh, such cases could very well be outside the common code paths, so it 
doesn't explode instantly for everybody.  They'll be time bombs instead.

cheers,
   Gerd