From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlI6p-0003Wp-Hl for qemu-devel@nongnu.org; Mon, 25 Jul 2011 06:10:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlI6o-0000Qq-L8 for qemu-devel@nongnu.org; Mon, 25 Jul 2011 06:09:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54801) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlI6o-0000Qi-C0 for qemu-devel@nongnu.org; Mon, 25 Jul 2011 06:09:58 -0400 Message-ID: <4E2D40F0.1070604@redhat.com> Date: Mon, 25 Jul 2011 13:09:52 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D3CC2.7000206@redhat.com> <0AF62DBC-C10D-4C06-9FE3-CCE8AF912462@suse.de> <4E2D3F3E.70303@redhat.com> <060B54D0-566A-4749-BD7C-B3035C7E1792@suse.de> In-Reply-To: <060B54D0-566A-4749-BD7C-B3035C7E1792@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , qemu-devel@nongnu.org, kvm@vger.kernel.org On 07/25/2011 01:04 PM, Alexander Graf wrote: > On 25.07.2011, at 12:02, Avi Kivity wrote: > > > On 07/25/2011 12:56 PM, Alexander Graf wrote: > >> > > >> > That argument can be used to block any change. You'll get used to it in time. The question is, is the new interface better or not. > >> > >> I agree that it keeps you from accidently malloc'ing a struct of pointer size. But couldn't we also just add this to checkpatch.pl? > > > > Better APIs trump better patch review. > > Only if you enforce them. The only sensible thing for QEMU_NEW (despite the general rule of upper case macros, I'd actually prefer this one to be lower case though since it's so often used) would be to remove qemu_malloc, declare malloc() as unusable and convert all users of qemu_malloc() to qemu_new(). Some qemu_mallocs() will remain (allocating a byte array or something variable sized). I agree qemu_new() will be nicer, but that will have to wait until Blue is several light-days away from Earth. -- error compiling committee.c: too many arguments to function