From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHKS7-0000Lh-En for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:59:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHKS6-0000LR-Uy for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:59:19 -0500 Received: from [199.232.76.173] (port=40450 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHKS6-0000LK-RD for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:59:18 -0500 Received: from bhuna.collabora.co.uk ([93.93.128.226]:32872) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NHKS6-0005Fd-9i for qemu-devel@nongnu.org; Sun, 06 Dec 2009 11:59:18 -0500 Message-ID: <4B1BE2BD.900@collabora.co.uk> Date: Sun, 06 Dec 2009 16:58:37 +0000 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B193DA5.6040507@codemonkey.ws> <4B1A9359.8080305@redhat.com> <4B1A9BF4.2090909@redhat.com> <4B1AE7E3.9000905@collabora.co.uk> <4B1AE8BA.7050207@redhat.com> <4B1AEBE0.4060204@collabora.co.uk> <4B1BACAF.5050203@redhat.com> In-Reply-To: <4B1BACAF.5050203@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Blue Swirl , Paul Brook , Markus Armbruster , qemu-devel@nongnu.org Avi Kivity wrote: > On 12/06/2009 01:25 AM, Ian Molton wrote: >> Avi Kivity wrote: >> >> >>> It's not that it doesn't have a way to report failure, it's that it >>> doesn't fail. Do you prefer functions that fail and report it to >>> functions that don't fail? >>> >> You have a way of allocating memory that will _never_ fail? > > Sort of. 'sort of' never ? > Did you look at the code? Yes. Its hardly infallible. >> well, make sure n is not 0. Its not that hard. I dont think I've *ever* >> had a situation where I wanted to pass 0 to malloc. > > There are multiple such cases in the code. > >>>> stick to what people know, and LART them for misuse of it if necessary. >>>> >>> The LART is a crash, great. >>> >> No, the LART would be a 'your patch does this wrong, try this:' > > What about existing usage? Will you audit all the existing calls? mark qemu_malloc as deprecated. don't include new patches that use it. Plenty of time to fix the broken uses... -Ian