From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof Date: Fri, 23 Oct 2015 15:55:12 +0100 Message-ID: <1445612112.2374.213.camel@citrix.com> References: <1443986642-24392-1-git-send-email-julien.grall@citrix.com> <562A3295.6010901@citrix.com> <1445607059.2374.165.camel@citrix.com> <562A57D902000078000AE2A2@prv-mh.provo.novell.com> <562A3D0D.3000806@citrix.com> <562A5D4402000078000AE310@prv-mh.provo.novell.com> <1445610702.2374.199.camel@citrix.com> <562A625102000078000AE347@prv-mh.provo.novell.com> <562A47B1.7030400@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZpdkZ-0005Kl-9D for xen-devel@lists.xenproject.org; Fri, 23 Oct 2015 14:55:23 +0000 In-Reply-To: <562A47B1.7030400@citrix.com> 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 , Jan Beulich Cc: Ian Jackson , Tim Deegan , Keir Fraser , Wei.Liu2@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote: > On 23/10/15 15:37, Jan Beulich wrote: > > > > > On 23.10.15 at 16:31, wrote: > > > On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote: > > > > No, the validating script is a nice-to-have, but nothing more. What > > > > I was referring to was a patch to drop the use of this gcc > > > > extension. > > > > > > Then I'm confused. This patch turns a typeof into a __typeof__. In < > > > 56126D8702000078000A80AC@prv-mh.provo.novell.com> you said "typeof() > > > is a > > > gcc extension". > > > > > > Are you now saying that __typeof__ also a gcc extension too? > > > > > > I was under the impression that __typeof__ was standard (by some cxx > > > at > > > least) and your mail reinforced that (possibly wrong) impression. > > > > There's no typeof or __typeof__ in C11 or any earlier standard. > > I'm sorry if earlier replies of mine gave a different impression. > > > > > https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you > > > are > > > writing a header file that must work when included in ISO C programs, > > > write > > > __typeof__ instead of typeof", which also lead me to believe > > > __typeof__ was > > > OK from this PoV. > > > > That's solely to prevent name space issues - __typeof__ is a > > reserved name, while typeof isn't. > > Thank you for the explanation. I think we can do the same as x86 does > i.e: > > #define set_xen_guest_handle_raw(hnd, val) \ > do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0; \ > (hnd).p = val; \ > } while ( 0 ) This evaluates hnd twice, which I assumed we wanted to avoid. But if that is OK for x86 in this situation then there is no harm doing it on ARM too[0]. But in that case I think we would just do (hnd).q = val ; (hnd).p = val rather than messing with &, casts and *. I think x86 does it that way because .q doesn't exist in the __guest_handle_foo, only the __guest_handle_64_foo, but it exists in both on ARM. We also know that sizeof(hnd) == 8 always on both arm subarches. Maybe it would be worth checking sizeof(hnd.p) == 8 (i.e. whether the real type completely fills the padding container), I don't know. Ian. [0] But maybe do check for arm specific set_guest_handle(foo++, bar) type constructs which slipped in... > > I will send a new version of this patch. > > Regards, > >