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

[Eric Blake <eblake@redhat.com>]

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