From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH] Introduce QEMU_NEW() Date: Mon, 25 Jul 2011 12:59:18 +0200 Message-ID: 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> <4E2D40F0.1070604@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Maydell , Alexander Graf , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: In-Reply-To: <4E2D40F0.1070604@redhat.com> (Avi Kivity's message of "Mon, 25 Jul 2011 13:09:52 +0300") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org Avi Kivity writes: > 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). Byte array: add the obvious type-safe allocator for a variable-sized array T[N], then use it with unsigned char for T. In fact, I find QEMU_NEW() pretty pointless without a buddy for arrays. Still not covered: allocating a struct with a variable-size array as final member. I guess a solution for that can be found if we care enough. [...]