xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei.Liu2@citrix.com, KeirFraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof
Date: Tue, 27 Oct 2015 10:20:01 +0000	[thread overview]
Message-ID: <562F4FD1.5070502@citrix.com> (raw)
In-Reply-To: <562F3EBF02000078000AEED0@prv-mh.provo.novell.com>

Hi Jan,

On 27/10/2015 08:07, Jan Beulich wrote:
>>>> On 26.10.15 at 19:08, <julien.grall@citrix.com> 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

  reply	other threads:[~2015-10-27 10:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-04 19:24 [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof Julien Grall
2015-10-05 10:31 ` Jan Beulich
2015-10-06 17:25   ` Julien Grall
2015-10-07  6:31     ` Jan Beulich
2015-10-07  8:28       ` Ian Campbell
2015-10-05 13:40 ` Wei Liu
2015-10-06  9:43   ` Julien Grall
2015-10-23 13:13 ` Julien Grall
2015-10-23 13:30   ` Ian Campbell
2015-10-23 13:52     ` Jan Beulich
2015-10-23 13:58       ` Julien Grall
2015-10-23 14:16         ` Jan Beulich
2015-10-23 14:31           ` Ian Campbell
2015-10-23 14:35             ` Ian Campbell
2015-10-23 14:37             ` Jan Beulich
2015-10-23 14:44               ` Julien Grall
2015-10-23 14:55                 ` Ian Campbell
2015-10-23 15:11                   ` Jan Beulich
2015-10-26 18:08                   ` Julien Grall
2015-10-27  8:05                     ` Jan Beulich
2015-10-28 15:44                       ` Julien Grall
2015-10-28 15:52                         ` Jan Beulich
2015-10-29 11:40                           ` Stefano Stabellini
2015-10-27  8:07                     ` Jan Beulich
2015-10-27 10:20                       ` Julien Grall [this message]
2015-10-23 14:03       ` Ian Campbell
2015-10-23 14:24         ` Jan Beulich
2015-10-23 14:48           ` Ian Campbell
2015-10-23 14:55             ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=562F4FD1.5070502@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Wei.Liu2@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).