[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] xen/common: fix MISRA R7.2 violations in crc32/unlzma/bunzip2
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Precious <andrewprecious388@xxxxxxxxx>
- Date: Mon, 28 Sep 2026 11:08:28 +0300
- Arc-authentication-results: i=1; mx.google.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=CUH9DC8D35xTowIT4lolyJrNK0/lvV7rYDhSa0knUts=; fh=dPy7QBf/9o5W9g82yvkNJlgbMjV4luS1EvQbQLsWpBI=; b=Nmt6++VOpNIRjjiQ1ryObbz/m73bBD5qppN+gzbHi9a+M60Tob95S4PLjXWs48DAUY dy1QiiMBTl2MH4s8WmFbUJvMQxg8hmg3uFllhC3RyFGihvJjuxXAJkWatudg5/UUJjim VPPxr+PJGBL1RwFE85C7+HApP/msznGgsxodlmOs2IvnS1yUT6SjDDtkiJgghdntLHfD v9/UJ6pPd7TTGk6xRLjXTxIkI95n6Eyz7ExkGtds027vpX/KJZkFuEDqEEAhvFiTRa1q HpU+DELEV6T3362ZsSkINKgdy35xZ0ZoPPjAiTLjcQTLMx03vVi5brArQDUN/8hXOnx4 jLxw==; darn=lists.xenproject.org
- Arc-seal: i=1; a=rsa-sha256; t=1790582920; cv=none; d=google.com; s=arc-20260327; b=EtDwyrMfcyWlCKSokxvNUTuWyqkXLTR/ChE3KcgOBSNrhS/EkX2QscC4dRYyRESECz anQ1WFAQZwMDxHjQauqvAxTq4Krt28PpVx5jIGxNPrztLaa1XQJkuGzIGzrbvWONbhH+ 6oqC7cWw1Ye1BWCCgVQLUvs8PIcoz0AS8PmC2+RhuwhOf48yx5+TpS9Uuw5Iz213rha0 otPT+dLX0ciU6Ts1KxG4BrUwBRvhSjQiirdNf17VjhQ2N87oA7df974QWDWZ+iXy/zAa tEkqu/vHoL5VBnHNBJBfhm3DbAMjGOfRyn7u97CqL4jZlFjtQS2Qu44hQU2BgXDRIXpD NKJA==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References:MIME-Version"
- Cc: andrew.cooper3@xxxxxxxxxx, anthony.perard@xxxxxxxxxx, michal.orzel@xxxxxxx, julien@xxxxxxx, roger@xxxxxxxxxxxxxx, sstabellini@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 28 Sep 2026 08:08:49 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Won't the lack of full misra rules compliance(even for linux code) hinder Xens' security certification process?
Though I do understand the amount of work needed to clean imported code & still make sure that it's as close as possible to the original
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
|
