From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: [PATCH for-4.6] xen/public: arm: Use __typeof__
 rather than typeof
Date: Tue, 27 Oct 2015 10:20:01 +0000
Message-ID: <562F4FD1.5070502@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> <1445612112.2374.213.camel@citrix.com>
	<562E6C09.90607@citrix.com>
	<562F3EBF02000078000AEED0@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=7357d1dde=julien.grall@citrix.com>)
	id 1Zr1MM-0000GU-PO
	for xen-devel@lists.xenproject.org; Tue, 27 Oct 2015 10:20:06 +0000
In-Reply-To: <562F3EBF02000078000AEED0@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
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
List-Id: xen-devel@lists.xenproject.org

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