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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Jan,

On 27/10/2015 08:07, Jan Beulich wrote:
> > > > On 26.10.15 at 19:08, <julien.grall@xxxxxxxxxx> wrote:
> > On 23/10/15 15:55, Ian Campbell wrote:
> > > On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote:
> > > > 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 *.
> > Which is, based on the ISO C spec [1], unspecified. See 6.2.6.1#7:
> >
> > "When a value is stored in a member of an object of union type, the
> > bytes of the object representation that do not correspond to that member
> > but do correspond to other members take unspecified values, but the
> > value of the union object shall not thereby become a trap
> > representation."
> Question is - why would you need both assignments? Afaics the
> .q one would suffice.
Agree .q would suffice only and only if we replace all the usage of .p 
by .q with a cast.
Otherwise, accessing .p just after .q may be implementation-defined (see 
[1]).
Anyway, as you sent a patch to drop get_xen_guest_handle, I will see to 
implement Ian Jackson suggestion. I.e:
typedef union {
 uint64_t actual;
 type *for_check }

#define set_xen_guest_handle_raw(hnd, val)      \
  do {                                          \
        hnd.actual = (uint64_t)(val);           \
        sizeof((val) == ((hnd).for_check)
  }

Regards,

[1]  http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

--
Julien Grall

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