Re: [PATCH 1/2] x86/e820: fix build with gcc9

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Charles Arnold <CARNOLD@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>, Juergen Gross <jgross@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH 1/2] x86/e820: fix build with gcc9
Date: Thu, 7 Mar 2019 11:46:08 +0100	[thread overview]
Message-ID: <20190307104608.dsexwz7dn6qceel7@Air-de-Roger> (raw)
In-Reply-To: <5C80F30F020000780021C623@prv1-mh.provo.novell.com>

On Thu, Mar 07, 2019 at 03:31:43AM -0700, Jan Beulich wrote:
> e820.c: In function ‘clip_to_limit’:
> .../xen/include/asm/string.h:10:26: error: ‘__builtin_memmove’ offset [-16, -36] is out of the bounds [0, 20484] of
> object ‘e820’ with type ‘struct e820map’ [-Werror=array-bounds]
>    10 | #define memmove(d, s, n) __builtin_memmove(d, s, n)
>       |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~
> e820.c:404:13: note: in expansion of macro ‘memmove’
>   404 |             memmove(&e820.map[i], &e820.map[i+1],
>       |             ^~~~~~~
> e820.c:36:16: note: ‘e820’ declared here
>    36 | struct e820map e820;
>       |                ^~~~
> 
> While I can't see where the negative offsets would come from, converting
> the loop index to unsigned type helps. Take the opportunity and also
> convert several other local variables and copy_e820_map()'s second
> parameter to unsigned int (and bool in one case).

I also cannot see how you can end up with negative offsets, but
changing to unsigned int is definitely and improvement IMO.

> Reported-by: Charles Arnold <carnold@suse.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks.

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