From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlMsc-0008Iw-Fg for qemu-devel@nongnu.org; Mon, 25 Jul 2011 11:15:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QlMsb-00020V-Dw for qemu-devel@nongnu.org; Mon, 25 Jul 2011 11:15:38 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:37755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QlMsb-00020H-BV for qemu-devel@nongnu.org; Mon, 25 Jul 2011 11:15:37 -0400 Received: by gxk26 with SMTP id 26so2718429gxk.4 for ; Mon, 25 Jul 2011 08:15:36 -0700 (PDT) Message-ID: <4E2D8896.7070100@codemonkey.ws> Date: Mon, 25 Jul 2011 10:15:34 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D876C.3010300@redhat.com> In-Reply-To: <4E2D876C.3010300@redhat.com> 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: Jes Sorensen Cc: Stefan Hajnoczi , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org On 07/25/2011 10:10 AM, Jes Sorensen wrote: > On 07/25/11 12:06, Stefan Hajnoczi wrote: >>> +#define QEMU_NEW(type) ((type *)(qemu_malloc(sizeof(type)))) >>>> +#define QEMU_NEWZ(type) ((type *)(qemu_mallocz(sizeof(type)))) >> Does this mean we need to duplicate the type name for each allocation? >> >> struct foo *f; >> >> ... >> f = qemu_malloc(sizeof(*f)); >> >> Becomes: >> >> struct foo *f; >> >> ... >> f = QEMU_NEW(struct foo); >> >> If you ever change the name of the type you have to search-replace >> these instances. The idomatic C way works well, I don't see a reason >> to use QEMU_NEW(). > > You're right, and it will promote even more abuse of the ugly typedefs. > This really makes the code less readable, especially for outsiders :( I don't think it really matters either way. If some people prefer to use g_new(struct foo, 1) vs. g_malloc(sizeof(*f)), I don't think it significantly impacts overall code readability. But having nice, documentation for key internal APIs does which is why using the glib interfaces makes sense IMHO. Regards, Anthony Liguori > > Jes > > >