Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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, <ian.campbell@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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,
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel