From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHgQX-0005oF-AS for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:27:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHgQS-0005ma-1d for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:27:08 -0500 Received: from [199.232.76.173] (port=41416 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHgQP-0005mE-Pb for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:27:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7090) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHgQP-0007m7-Vd for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:27:02 -0500 Message-ID: <4B1D2CC2.7010806@redhat.com> Date: Mon, 07 Dec 2009 18:26:42 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B1D2462.3070000@codemonkey.ws> <4B1D2696.5080003@redhat.com> <4B1D27EE.7060400@codemonkey.ws> <4B1D292D.4010700@redhat.com> <4B1D2B54.40402@codemonkey.ws> In-Reply-To: <4B1D2B54.40402@codemonkey.ws> 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: Anthony Liguori Cc: Kevin Wolf , Paul Brook , Markus Armbruster , qemu-devel@nongnu.org On 12/07/2009 06:20 PM, Anthony Liguori wrote: > Avi Kivity wrote: >>> Covering every qemu_malloc instance this close to the GA is too >>> risky. I agree that having separate behavior is less than ideal but >>> I think it's the only sane way forward. >>> >> >> I don't understand why. What's so insane about Markus' patch? >> Allowing size=0 for both developer and production builds? > > There is a bug here. Callers are calling qemu_malloc incorrectly. > > There is an open discussion about how to address it--fix all callers > of qemu_malloc() or allow size=0. Since there isn't agreement, a > compromise of sticking to the current behavior for the development > tree, and using the later for production since we can't guarantee the > former seems reasonable. If we apply the patch, the callers are no longer incorrect. Since we're winding down development on that tree, I see no reason for the production build to be correct and the development tree to be incorrect. >> It seems like the least risky, least change approach to me. Exactly >> what we want for 0.12. > > The risk is that everyone will agree to this approach in the next two > weeks. I'm fairly certain no amount of discussion on qemu-devel is > going to lead to that. You've already agreed to it for the production build. There's no gain in having separate behaviour for development and production, when a tree is headed towards production. -- error compiling committee.c: too many arguments to function