Re: Empty struct in public headers Was: Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU

[Ian Campbell <Ian.Campbell@citrix.com>]

On Tue, 2014-11-18 at 15:49 +0000, Julien Grall wrote:
> (Rename the mail and strip the cc list)
> 
> On 11/18/2014 03:35 PM, Ian Jackson wrote:
> > Julien Grall writes ("Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU"):
> >> On 11/18/2014 03:10 PM, Ian Jackson wrote:
> >>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures').  I
> >>> would be very surprised if clang didn't support them too.
> >>
> >> AFAIK, clang doesn't complain about empty structures.
> > 
> > Right.
> > 
> >>> AIUI our policy, gcc extensions are fine except in the Xen public
> >>> headers.
> >>
> >> We have at least 2 "empty" structure on the ARM public header.
> > 
> > That ought to be fixed, in case anyone ever wants to build ARM guests
> > with Norcroft C or something.
> > 
> > Does the size of these structs matter ?
> 
> The 2 structures are arch_vcpu_info and arch_shared_info.
> 
> They are used only at the end of the structure vcpu_info (resp.
> shared_info). So I guess we could fix it?

arch_vcpu_info isn't at the end of vcpu_info (vcpu_time_info follows it)
and also vcpu_info is part of an array at the start of shared_info (an
array of 1 on ARM, but things still follow it). I'm also not sure of the
impact on the vcpu placement hypercall or the uses of it.

So it looks like changing vcpu_info at least will be hard/impossible. If
we want rid of these empty structs then I think an ifdef at the point of
use is the only option :-(

> >> Would something like below be better?
> >>
> >> struct
> >> {
> >>   int dummy:1
> >> };
> > 
> > I don't see why you wouldn't just do
> >    struct blah { char dummy; };
> > or even int dummy;
> 
> It was to avoid using more bit than necessary. I will use your solution.
> 
> Regards,
>