From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Empty struct in public headers Was: Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3 for domU Date: Tue, 18 Nov 2014 16:21:02 +0000 Message-ID: <1416327662.17982.24.camel@citrix.com> References: <1414695092-20761-1-git-send-email-julien.grall@linaro.org> <54535E240200007800043DAC@mail.emea.novell.com> <546B5F15.5060702@linaro.org> <21611.24907.144396.509457@mariner.uk.xensource.com> <546B650D.8040304@linaro.org> <21611.26449.963393.613516@mariner.uk.xensource.com> <546B6AA5.1050409@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XqlXz-0005Vs-Ko for xen-devel@lists.xenproject.org; Tue, 18 Nov 2014 16:22:31 +0000 In-Reply-To: <546B6AA5.1050409@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: stefano.stabellini@citrix.com, tim@xen.org, Ian Jackson , Jan Beulich , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org 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, >