From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW() Date: Mon, 25 Jul 2011 09:43:26 -0500 Message-ID: <4E2D810E.3060104@codemonkey.ws> References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D5D7C.40208@codemonkey.ws> <4E2D5F0D.2040303@redhat.com> <4E2D5FB3.7000906@codemonkey.ws> <4E2D7CD7.1060707@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Blue Swirl , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Max Filippov Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:33010 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751843Ab1GYOna (ORCPT ); Mon, 25 Jul 2011 10:43:30 -0400 Received: by gyh3 with SMTP id 3so2253266gyh.19 for ; Mon, 25 Jul 2011 07:43:29 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 07/25/2011 09:30 AM, Max Filippov wrote: >>>>>>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >>>>>>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >>>>>> >>>>>> Just use g_new() and g_new0() >>>>>> >>>>> >>>>> These bypass qemu_malloc(). Are we okay with that? >>>> >>>> Yes. We can just make qemu_malloc use g_malloc. >>> >>> It would be also possible to make g_malloc() use qemu_malloc(). That >>> way we could keep the tracepoints which would lose their value with >>> g_malloc() otherwise. >> >> Or just add tracepoints to g_malloc()... >> >> But yeah, the point is, we ought to unify to a standard library function >> instead of inventing our own version of everything. > > What about zero-size allocations for which g_malloc would return NULL? Using a standard, well documented, rich interface trumps any arguments about the semantics of zero-sized allocation. Regards, Anthony Liguori