Adding the U suffix. No functional change.

MISRA C Rule 7.2 demands a "u" or "U" suffix on all
integer constants with unsigned type. On 32-bit int targets
constants >= 0x80000000 (e.g. 0xEDB88320, 0xFFFFFFFF,
0x80000000, 0x04C11DB7) must be written explicitly unsigned.


Signed-off-by: Andrew Mbugua <andrewprecious388@gmail.com>
---
diff --git a/xen/common/bunzip2.c b/xen/common/bunzip2.c
index 79f17162b1..6345a064cd 100644
--- a/xen/common/bunzip2.c
+++ b/xen/common/bunzip2.c
@@ -650,7 +650,7 @@ static int __init start_bunzip(struct bunzip_data **bdp, void *inbuf, int len,
 	for (i = 0; i < 256; i++) {
 		c = i << 24;
 		for (j = 8; j; j--)
-			c = c&0x80000000 ? (c << 1)^0x04c11db7 : (c << 1);
+			c = c&0x80000000U ? (c << 1)^0x04c11db7U : (c << 1);
 		bd->crc32Table[i] = c;
 	}
 
diff --git a/xen/common/unlzma.c b/xen/common/unlzma.c
index 56359420aa..bd42984f15 100644
--- a/xen/common/unlzma.c
+++ b/xen/common/unlzma.c
@@ -106,7 +106,7 @@ static inline void __init rc_init(struct rc *rc,
 	rc->ptr = rc->buffer;
 
 	rc->code = 0;
-	rc->range = 0xFFFFFFFF;
+	rc->range = 0xFFFFFFFFU;
 }
 
 static inline void __init rc_init_code(struct rc *rc)
diff --git a/xen/common/xz/crc32.c b/xen/common/xz/crc32.c
index 092a74fbab..0368d8793f 100644
--- a/xen/common/xz/crc32.c
+++ b/xen/common/xz/crc32.c
@@ -19,7 +19,7 @@ XZ_EXTERN uint32_t __initdata xz_crc32_table[256];
 
 XZ_EXTERN void __init xz_crc32_init(void)
 {
-	const uint32_t poly = 0xEDB88320;
+	const uint32_t poly = 0xEDB88320U;
 
 	uint32_t i;
 	uint32_t j;

On 24.09.2026 14:24, Andrew Mbugua wrote:
> Adding the U suffix. No functional change.
> 
> MISRA C Rule 7.2 demands a "u" or "U" suffix on all
> integer constants with unsigned type. On 32-bit int targets
> constants >= 0x80000000 (e.g. 0xEDB88320, 0xFFFFFFFF,
> 0x80000000, 0x04C11DB7) must be written explicitly unsigned.

0x04C11DB7 is small enough to be okay without suffix. Adding one nevertheless
is fine, but the description wants to be correct.

Furthermore, rule 7.2 is clean as per tagging.ecl. As per exclude-list.json
common/bunzip2.c, common/un*.c, and common/xz/* are excluded from scanning.
The fact that the change is benign to our present scanning status imo also
wants expressing in the description.

And then there is the question whether we want to fiddle with these files in
the first place, when really we'd prefer them to stay as closely in sync with
their originals as possible.

> --- a/xen/common/bunzip2.c
> +++ b/xen/common/bunzip2.c
> @@ -650,7 +650,7 @@ static int __init start_bunzip(struct bunzip_data **bdp, void *inbuf, int len,
>  	for (i = 0; i < 256; i++) {
>  		c = i << 24;
>  		for (j = 8; j; j--)
> -			c = c&0x80000000 ? (c << 1)^0x04c11db7 : (c << 1);
> +			c = c&0x80000000U ? (c << 1)^0x04c11db7U : (c << 1);

Please (if we go with fiddling with these files) can you also add the
missing blanks around & and ^ at this occasion?

Jan