|
From: | Eric Blake |
Subject: | Re: [Qemu-devel] [PATCH 2/3] qobject: assume base of a qobject is at offset 0 |
Date: | Wed, 21 Mar 2018 10:29:46 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
On 03/21/2018 09:49 AM, Paolo Bonzini wrote:
On 21/03/2018 15:21, Marc-André Lureau wrote:Yeah, I tried a few of those approaches. Here the problem is that QObject doesn't have base field. So you get a compile time error with a QObject * as argument.So the compiler requires &(x)->base to resolve even when it is not on the branch that gets selected?Unfortunately, yes, all branches must compile apparently (I know)...Ugh, and that's indeed true of _Generic too. These don't compile: struct s1 { int y; }; struct s2 { int z; }; #define f(x) _Generic(x, struct s1: (x).y, struct s2: (x).z) int f1(struct s1 *s) { return f(*s); } int f2(struct s2 *s) { return f(*s); } :( Then I guess Marc-André's realization is ugly but unavoidable.
Not necessarily - can we use multiple layers of macros? (Untested) #define QOBJECT_0(x) x #define QOBJECT_1(x) ({ \ QEMU_BUILD_BUG_ON(offsetof(typeof(*x), base)); \ &(x)->base; }) #define QOBJECT(x) QOBJECT_ ## QEMU_GENERIC(x, \ (QObject *, 0), (const QObject *, 0), 1)(x) or with an additional layer of glue() if neededThat is, reduce the QEMU_GENERIC expansion into something that generates only a single preprocessor token, where we then use to decide which OTHER macro to expand, so that we are only evaluating &(x)->base when we selected the derived types.
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
[Prev in Thread] | Current Thread | [Next in Thread] |