From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHgam-0000iP-B2 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:37:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHgag-0000gm-Nh for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:37:42 -0500 Received: from [199.232.76.173] (port=58352 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHgaf-0000gZ-Ee for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:37:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55649) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHgaf-0008Qm-K2 for qemu-devel@nongnu.org; Mon, 07 Dec 2009 11:37:37 -0500 Message-ID: <4B1D2F38.1040604@redhat.com> Date: Mon, 07 Dec 2009 18:37:12 +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> <4B1D2CC2.7010806@redhat.com> <4B1D2E2E.6060907@codemonkey.ws> In-Reply-To: <4B1D2E2E.6060907@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:32 PM, Anthony Liguori wrote: >> 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. > > > The problem with this whole discussion is taking the position that one > form is "correct" while the other form is "incorrect". It's not so > black and white. > > I don't think a reasonable person can claim that either form of > qemu_malloc() is absolutely correct while the other is incorrect. You > may think one is better than the other but clearly, that sentiment is > not universally shared. > I'm less concerned about qemu_malloc() and more about qemu itself (though qemu_malloc() as patched fulfils all the standard's requirements). > If we change the production build, we eliminate the immediate problem. What about developers that hit the assert? Do they send patches that fix code that works in production just so they can run in developer mode? > For 0.13, we can reduce the usage of qemu_malloc() such that it stops > becoming an issue. Then no one ever has to agree about which form is > better and we can move on with our lives. I agree, and the proposed changes are an improvement in their own right. -- error compiling committee.c: too many arguments to function