Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Xen>
  3. Devel
[XEN PATCH 03/10] automation/eclair_analysis: deviate macro count_args_ for MISRA Rule 20.7
nicola.vetrini at bugseng
Apr 23, 2024, 8:12 AM
Post #1 of 4 (12 views)
Permalink
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.

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
Re: [XEN PATCH 03/10] automation/eclair_analysis: deviate macro count_args_ for MISRA Rule 20.7 [ In reply to ]
sstabellini at kernel
Apr 24, 2024, 5:28 PM
Post #2 of 4 (8 views)
Permalink
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.


> 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
>
Re: [XEN PATCH 03/10] automation/eclair_analysis: deviate macro count_args_ for MISRA Rule 20.7 [ In reply to ]
nicola.vetrini at bugseng
Apr 29, 2024, 5:18 AM
Post #3 of 4 (4 views)
Permalink
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)
Re: [XEN PATCH 03/10] automation/eclair_analysis: deviate macro count_args_ for MISRA Rule 20.7 [ In reply to ]
sstabellini at kernel
May 1, 2024, 12:54 PM
Post #4 of 4 (4 views)
Permalink
On Mon, 29 Apr 2024, Nicola Vetrini wrote:
> 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

OK

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal