Re: [Xen-devel] libxc: Casting of xen virtual address type xen_vaddr_t to signed int64 type: (int64_t)vaddr

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.05.19 at 16:10, <viktor.mitin.19@xxxxxxxxx> wrote:
> Hi Jan and Andrew, All
> 
> From standard:
> The result of E1 >> E2 is E1 right-shifted E2 bit positions.
> If E1 has an unsigned type or if E1 has a signed type and a nonnegative 
> value,
> the value of the result is the integral part of the quotient of E1 / 2E2.
> If E1 has a signed type and a negative value,
> the resulting value is implementation-defined.
> 
> To rephrase: in case of right shifting and when the original number is 
> negative,
> the standard does not define whether the shift is arithmetic or logical
> (i.e. will it preserve the sign or not).
> 
> In our example, in the case when
> (int64_t)vaddr < 0
> the result of next shift is 'implementation-defined' (and not
> 'undefined behavior'):
> (int64_t)vaddr >> 63
> 
> Mean that result of "(int64_t)vaddr >> 63" can be 0 or 1.
> So the next code may not work properly in case of another 'implementations'.
> With another compiler (i.e. clang, etc) this code may introduce bugs
> which are hard to find.
> 
> ((int64_t)vaddr >> 47) == ((int64_t)vaddr >> 63)
> 
> For this reason it is better to avoid implementation-defined code.

Well, ideally we'd like to get away without using implementation
defined behavior. But I'm afraid we're quite far from that, and
we'd not always be willing to accept the worse source and/or
binary code that would be needed to avoid it.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel