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

[Eric Blake]

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