From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW() Date: Mon, 25 Jul 2011 17:28:12 +0200 Message-ID: <4E2D8B8C.2050500@redhat.com> References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D876C.3010300@redhat.com> <4E2D8896.7070100@codemonkey.ws> <4E2D8904.5080200@redhat.com> <4E2D89C7.8010004@redhat.com> <4E2D89E1.20401@redhat.com> <4E2D8AB4.3090106@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Stefan Hajnoczi , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22560 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776Ab1GYPaP (ORCPT ); Mon, 25 Jul 2011 11:30:15 -0400 In-Reply-To: <4E2D8AB4.3090106@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 07/25/11 17:24, Avi Kivity wrote: > On 07/25/2011 06:21 PM, Jes Sorensen wrote: >> On 07/25/11 17:20, Avi Kivity wrote: >> > On 07/25/2011 06:17 PM, Jes Sorensen wrote: >> >> Using the commands consistently does have an impact, and at least >> with >> >> qemu_malloc() it is obvious what they are and how they behave. The >> >> proposed macros on the other hand requires everybody to go look up >> the >> >> macro to find out what it is trying to do. >> > >> > That's true for every single function and macro that qemu defines. >> > >> >> Of course, and every time it adds complexity for reading it. In this >> particular case it seems to simply make the code worse for no gain. > > I guess type safety doesn't matter to you. In my experience it's one of the lesser problems in the code. Jes