qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] qobject: assume base of a qobject is at off


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]