From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: xen-devel@lists.xenproject.org, michal.orzel@amd.com,
xenia.ragiadakou@amd.com, ayan.kumar.halder@amd.com,
consulting@bugseng.com, bertrand.marquis@arm.com, julien@xen.org,
Simone Ballarin <simone.ballarin@bugseng.com>,
Doug Goldstein <cardoe@cardoe.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [XEN PATCH 03/10] automation/eclair_analysis: deviate macro count_args_ for MISRA Rule 20.7
Date: Mon, 29 Apr 2024 14:18:08 +0200 [thread overview]
Message-ID: <5b675fcdf688723bc6d4ea260d10004e@bugseng.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2404241727520.3940@ubuntu-linux-20-04-desktop>
On 2024-04-25 02:28, Stefano Stabellini wrote:
> On Tue, 23 Apr 2024, Nicola Vetrini wrote:
>> The count_args_ macro violates Rule 20.7, but it can't be made
>> compliant with Rule 20.7 without breaking its functionality. Since
>> it's very unlikely for this macro to be misused, it is deviated.
>
> That is OK but can't we use the SAF- framework to do it, given that it
> is just one macro?
>
> If not, this is also OK.
>
>
It would be more fragile, for no substantial gain
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> ---
>> automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
>> docs/misra/deviations.rst | 6 ++++++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index d21f112a9b94..c17e2f5a0886 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -445,6 +445,12 @@ not to parenthesize their arguments."
>> -config=MC3R1.R20.7,reports+={safe,
>> "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"}
>> -doc_end
>>
>> +-doc_begin="The argument 'x' of the count_args_ macro can't be
>> parenthesized as
>> +the rule would require, without breaking the functionality of the
>> macro. The uses
>> +of this macro do not lead to developer confusion, and can thus be
>> deviated."
>> +-config=MC3R1.R20.7,reports+={safe,
>> "any_area(any_loc(any_exp(macro(^count_args_$))))"}
>> +-doc_end
>> +
>> -doc_begin="Uses of variadic macros that have one of their arguments
>> defined as
>> a macro and used within the body for both ordinary parameter
>> expansion and as an
>> operand to the # or ## operators have a behavior that is
>> well-understood and
>> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
>> index ed0c1e8ed0bf..e228ae2e715f 100644
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -371,6 +371,12 @@ Deviations related to MISRA C:2012 Rules:
>> sanity checks in place.
>> - Tagged as `safe` for ECLAIR.
>>
>> + * - R20.7
>> + - The macro `count_args_` is not compliant with the rule, but is
>> not likely
>> + to incur in the risk of being misused or lead to developer
>> confusion, and
>> + refactoring it to add parentheses breaks its functionality.
>> + - Tagged as `safe` for ECLAIR.
>> +
>> * - R20.12
>> - Variadic macros that use token pasting often employ the gcc
>> extension
>> `ext_paste_comma`, as detailed in `C-language-toolchain.rst`,
>> which is
>> --
>> 2.34.1
>>
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
next prev parent reply other threads:[~2024-04-29 12:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 15:12 [XEN PATCH 00/10] Address violations of MISRA C Rule 20.7 Nicola Vetrini
2024-04-23 15:12 ` [XEN PATCH 01/10] libelf: address " Nicola Vetrini
2024-04-24 7:19 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 02/10] xen/page-defs: address violation " Nicola Vetrini
2024-04-24 7:20 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 03/10] automation/eclair_analysis: deviate macro count_args_ for MISRA " Nicola Vetrini
2024-04-25 0:28 ` Stefano Stabellini
2024-04-29 12:18 ` Nicola Vetrini [this message]
2024-05-01 19:54 ` Stefano Stabellini
2024-05-15 7:09 ` Nicola Vetrini
2024-05-15 7:15 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 04/10] drivers: char: address violation of MISRA C " Nicola Vetrini
2024-04-24 7:23 ` Jan Beulich
2024-04-24 10:07 ` Nicola Vetrini
2024-04-23 15:12 ` [XEN PATCH 05/10] xen/spinlock: address violations " Nicola Vetrini
2024-04-24 7:25 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 06/10] x86/pci: address violation " Nicola Vetrini
2024-04-24 7:26 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 07/10] x86/acpi: power: address violations of MISRA " Nicola Vetrini
2024-04-24 7:26 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 08/10] x86/hvm: hpet: address violations of MISRA C " Nicola Vetrini
2024-04-24 7:28 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 09/10] x86/debugreg: address violation " Nicola Vetrini
2024-04-24 7:28 ` Jan Beulich
2024-04-23 15:12 ` [XEN PATCH 10/10] x86/mm: address violations " Nicola Vetrini
2024-04-24 7:29 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b675fcdf688723bc6d4ea260d10004e@bugseng.com \
--to=nicola.vetrini@bugseng.com \
--cc=andrew.cooper3@citrix.com \
--cc=ayan.kumar.halder@amd.com \
--cc=bertrand.marquis@arm.com \
--cc=cardoe@cardoe.com \
--cc=consulting@bugseng.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=simone.ballarin@bugseng.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=xenia.ragiadakou@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.