From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH] Introduce QEMU_NEW() Date: Mon, 25 Jul 2011 13:02:39 +0200 Message-ID: References: <1311583872-362-1-git-send-email-avi@redhat.com> <4E2D448C.9030306@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Stefan Hajnoczi , Avi Kivity , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Kevin Wolf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60480 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751673Ab1GYLCn (ORCPT ); Mon, 25 Jul 2011 07:02:43 -0400 In-Reply-To: <4E2D448C.9030306@redhat.com> (Kevin Wolf's message of "Mon, 25 Jul 2011 12:25:16 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Kevin Wolf writes: > Am 25.07.2011 12:06, schrieb Stefan Hajnoczi: >> On Mon, Jul 25, 2011 at 9:51 AM, Avi Kivity wrote: >>> qemu_malloc() is type-unsafe as it returns a void pointer. Introduce >>> QEMU_NEW() (and QEMU_NEWZ()), which return the correct type. >>> >>> Signed-off-by: Avi Kivity >>> --- >>> >>> This is part of my memory API patchset, but doesn't really belong there. >>> >>> qemu-common.h | 3 +++ >>> 1 files changed, 3 insertions(+), 0 deletions(-) >>> >>> diff --git a/qemu-common.h b/qemu-common.h >>> index ba55719..66effa3 100644 >>> --- a/qemu-common.h >>> +++ b/qemu-common.h >>> @@ -186,6 +186,9 @@ void qemu_free(void *ptr); >>> char *qemu_strdup(const char *str); >>> char *qemu_strndup(const char *str, size_t size); >>> >>> +#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); > > Maybe we should allow this and make it the usual pattern: > > f = qemu_new(typeof(*f)); > > It's gcc specific, but we already don't care about portability to other > compilers in more places. > > On the other hand, how many bugs did we have recently that were caused > by a wrong sizeof for qemu_malloc? As far as I can say, there's no real > reason to do it. I think it's the same kind of discussion as with > forbidding qemu_malloc(0) (except that this time it just won't improve > things much instead of being really stupid). Side-stepping the stupid "OMG malloc(0) is weird, therefore we must make qemu_malloc(0) differently weird" controversy would be useful all by itself.