[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] misra: deviate MISRA C Rule 10.1 for boolean operands of arithmetic
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
- Date: Mon, 2 Nov 2026 16:43:23 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9ABfFHEX/1nXmaldgHj1APyoLHqmu/HToKqwkZSYceU=; b=K/06ZfHkf7DXEjPpCzVVtgkWqCTjn/jXiTQY/kmku2zknezeN3qalnDwvRFXRGXv4R3+Ezi0jVas6iO1nryZwg4Ch+55wAs+pcbdpPXX9Biqq4JfkhsB+FzqgUH8SWE26Tcotxohi0wFscPaWLjyLE3VzguPrKuSQNDMSIZRR2oC5FbhZBJN3qcMsB03gxyeJmLxL6CGESe9HxeBFnHEFLYnsLlRiZ8WOAJ5TFz/zUwO5d0BsJ/cKGTeOgyyeTyCmk2TRfEd+wm3Fvt6bEXMfUagqPVtLtlnWpqdg9ENYMvUzE0/A2hxJ+hsTDvVVTwGVdjkXDknR6NrCJwgbElYRg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XHwaYwy9mkB21TEeyNa7FPz9oEqbYiKpZEdF3kSG9qVeMFCF2WsK8Tk9NOIkscV1H06nQiB+m9qZrqcIjuIewpLEAUF9U64HmR/XLJyCFMighezyAEKYExuqJcEmhiClhDqQFxgGxJiSGNvknLK3+KKX+aYaKKyZdYs3k1QoDNsMKrUUMMufWGNhWjIXVfurmeQRY76f7DkVJctMl5x1KysSmd5nxOoMGMzmTdC888fK2Ip0doa20q10wSnd1qZKZvX6RiTWtqCMgqnvqPaQFRP7MS8rHIYluPU0gpyTlUjhzX+RFwF8Q3ObeEjqNbA5Z08emkxUSFVF+O69gF4F/g==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 02 Nov 2026 14:43:40 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11/2/26 12:52, Jan Beulich wrote:
On 02.11.2026 11:20, Dmytro Prokopchuk wrote:
On 10/26/26 13:13, Jan Beulich wrote:
On 19.10.2026 18:54, Dmytro Prokopchuk1 wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -335,6 +335,11 @@ still non-negative."
-config=MC3A2.R10.1,etypes+={safe,
"stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))",
"dst_type(ebool||boolean)"}
-doc_end
+-doc_begin="The result of relational, equality and logical negation operators has type int and value 0 or 1 (C99 6.5.8p6, 6.5.9p3, 6.5.3.3p5),
+so using it as an operand of an arithmetic operator is well defined and well known
to all Xen developers."
+-config=MC3A2.R10.1,etypes+={safe,
"stmt(operator(add||sub||mul||add_assign||sub_assign))",
"src_type(ebool||boolean)"}
+-doc_end
Why the restriction to add/sub/mul? The text ...
Because this is the pattern found in the Eclair's report, and it can be
deviated safely (as opposed to unary minus, division and remainder which
are not included intentionally).
Division and remainder aren't very useful with boolean operands, so can
surely be left out. However, more generally: How does "Eclair's report"
matter here? In deviation wording we want to go from what the Misra spec
says. The spec covers all operators. Hence any special casing we do
wants to be justified. And, right now at least, I see no justification
for restricting the deviation to just add/sub/mul.
Agreed, the report shouldn't be the argument.
The deviation should cover only the established idioms with a clear
meaning, and leave the rule's protection in place elsewhere. With a
Boolean operand these idioms are:
- + and - (and += / -=): "count it if the condition holds",
- * (and *=): "this value if the condition holds, else 0".
Other operators have no such idiom (at least, I'm not aware of them).
I can put this reasoning into the deviation text in v2. Would that be
acceptable?
Jan
|
