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 needed
That 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
