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

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel