Re: [Xen-changelog] [xen-unstable] [VMXASSIST] Cast to pointer type via long to avoid compile

Re: [Xen-changelog] [xen-unstable] [VMXASSIST] Cast to pointer type via long to avoid compile

[Rik van Riel]

Xen patchbot-unstable wrote:

> [VMXASSIST] Cast to pointer type via long to avoid compile
> warnings/errors with latest gcc versions.
> Signed-off-by: Keir Fraser <keir@xensource.com>

Are you sure you don't want these to be unsigned, seeing that
the x86-64 kernels have the top bit set for kernel addresses?

> diff -r 5c522692edd1 -r 1d0e75523636 tools/firmware/vmxassist/vm86.c
> --- a/tools/firmware/vmxassist/vm86.c	Wed Sep 27 16:22:17 2006 +0100
> +++ b/tools/firmware/vmxassist/vm86.c	Wed Sep 27 17:49:22 2006 +0100
> @@ -68,7 +68,7 @@ guest_linear_to_real(uint32_t base)
>  		return base;
>  
>  	if (!(oldctx.cr4 & CR4_PAE)) {
> -		l1_mfn = ((uint32_t *)gcr3)[(base >> 22) & 0x3ff];
> +		l1_mfn = ((uint32_t *)(long)gcr3)[(base >> 22) & 0x3ff];

-- 
All Rights Reversed

Re: Re: [Xen-changelog] [xen-unstable] [VMXASSIST] Cast to pointer type via long to avoid compile

[Keir Fraser]

On 28/9/06 8:23 pm, "Rik van Riel" <riel@redhat.com> wrote:

>> [VMXASSIST] Cast to pointer type via long to avoid compile
>> warnings/errors with latest gcc versions.
>> Signed-off-by: Keir Fraser <keir@xensource.com>
> 
> Are you sure you don't want these to be unsigned, seeing that
> the x86-64 kernels have the top bit set for kernel addresses?

It's the original type that determines whether sign extension happens, and
they are u32 or u64, so there are no sign-extending issues in the type
change from u32/u64 to long. 'long' is the same size as a pointer on x86, so
no widening/narrowing happens in the final cast to pointer type, so there
are also no sign-extending issues in the type change from long to pointer.
So the code should be fine as is and avoiding 'unsigned long' means we don't
end up wrapping 80 columns or needing extra line breaks.

 -- Keir