Certain macros are allowed to violate the Rule, since their meaning and
intended use is well-known to all Xen developers.

Variadic macros that rely on the GCC extension for removing a trailing
comma when token pasting the variable argument are similarly
well-understood and therefore allowed.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
This patch is intended as a follow-up to the patch accepting this Rule for Xen
---
 .../eclair_analysis/ECLAIR/deviations.ecl      | 10 ++++++++++
 docs/misra/deviations.rst                      | 18 ++++++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index fd32ff8a9cae..98e5ad146b8d 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -387,6 +387,16 @@ in assignments."
 {safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
 -doc_end
 
+-doc_begin="The token pasting in variadic macros cannot be replaced."
+-config=MC3R1.R20.12,macros+={deliberate, "variadic()"}
+-doc_end
+
+-doc_begin="Uses of # and ## operators within the following macros are
+deliberate."
+-config=MC3R1.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
+-doc_end
+
+
 #
 # General
 #
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 123c78e20a01..855c1c5579bb 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -330,6 +330,24 @@ Deviations related to MISRA C:2012 Rules:
        (4) as lhs in assignments.
      - 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
+       not easily replaceable.
+     - Tagged as `deliberate` for ECLAIR.
+
+   * - R20.12
+     - Macros that are used for runtime or build-time assertions contain
+       deliberate uses of an argument as both a regular argument and a
+       stringification token, to provide useful diagnostic messages.
+     - Tagged as `deliberate` for ECLAIR.
+
+   * - R20.12
+     - GENERATE_CASE is a special-purpose macro that allows some selected switch
+       statements to be more compact and readable. As such, the risk of
+       developer confusion in using such macro is deemed negligible.
+     - Tagged as `deliberate` for ECLAIR.
+
 Other deviations:
 -----------------
 
-- 
2.34.1

On 14.02.2024 12:26, Nicola Vetrini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -387,6 +387,16 @@ in assignments."
>  {safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
>  -doc_end
>  
> +-doc_begin="The token pasting in variadic macros cannot be replaced."
> +-config=MC3R1.R20.12,macros+={deliberate, "variadic()"}
> +-doc_end
> +
> +-doc_begin="Uses of # and ## operators within the following macros are
> +deliberate."

I don't think this is a good explanation. The use of those operators is
deliberate elsewhere as well.

> +-config=MC3R1.R20.12,macros+={deliberate, "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}

I said in another context already that it is necessary to separate
global scope macros from local helper ones. Any CU can introduce another
GENERATE_CASE(), and would be deviated here right away. In fact I
question applicability of the deviation to arm/arm64/vsysreg.c; I only
see it as applicable to arm/vcpreg.c.

Jan

On 2024-02-14 12:49, Jan Beulich wrote:
> On 14.02.2024 12:26, Nicola Vetrini wrote:
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -387,6 +387,16 @@ in assignments."
>>  {safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
>>  -doc_end
>> 
>> +-doc_begin="The token pasting in variadic macros cannot be replaced."
>> +-config=MC3R1.R20.12,macros+={deliberate, "variadic()"}
>> +-doc_end
>> +
>> +-doc_begin="Uses of # and ## operators within the following macros 
>> are
>> +deliberate."
> 
> I don't think this is a good explanation. The use of those operators is
> deliberate elsewhere as well.
> 

Implicitly this was intended to be delimited to its applicability scope 
- violations of Rule 20.12. I detailed the reasons that were brought up 
to keep using these macros as is in the deviations.rst file. I'm open to 
further refinements, though.

>> +-config=MC3R1.R20.12,macros+={deliberate, 
>> "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
> 
> I said in another context already that it is necessary to separate
> global scope macros from local helper ones. Any CU can introduce 
> another
> GENERATE_CASE(), and would be deviated here right away. In fact I
> question applicability of the deviation to arm/arm64/vsysreg.c; I only
> see it as applicable to arm/vcpreg.c.
> 

Why wouldn't this be applicable for vsysreg.c? I can certainly fine-tune 
the deviation, if needed

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

On 14.02.2024 16:31, Nicola Vetrini wrote:
> On 2024-02-14 12:49, Jan Beulich wrote:
>> On 14.02.2024 12:26, Nicola Vetrini wrote:
>>> +-config=MC3R1.R20.12,macros+={deliberate, 
>>> "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
>>
>> I said in another context already that it is necessary to separate
>> global scope macros from local helper ones. Any CU can introduce 
>> another
>> GENERATE_CASE(), and would be deviated here right away. In fact I
>> question applicability of the deviation to arm/arm64/vsysreg.c; I only
>> see it as applicable to arm/vcpreg.c.
> 
> Why wouldn't this be applicable for vsysreg.c? I can certainly fine-tune 
> the deviation, if needed

There the sole macro parameter is used in only one of the possible ways,
with ##, unless I'm overlooking something. Aiui it is mixed use which
would need a deviation.

Jan

On 2024-02-14 16:45, Jan Beulich wrote:
> On 14.02.2024 16:31, Nicola Vetrini wrote:
>> On 2024-02-14 12:49, Jan Beulich wrote:
>>> On 14.02.2024 12:26, Nicola Vetrini wrote:
>>>> +-config=MC3R1.R20.12,macros+={deliberate,
>>>> "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
>>> 
>>> I said in another context already that it is necessary to separate
>>> global scope macros from local helper ones. Any CU can introduce
>>> another
>>> GENERATE_CASE(), and would be deviated here right away. In fact I
>>> question applicability of the deviation to arm/arm64/vsysreg.c; I 
>>> only
>>> see it as applicable to arm/vcpreg.c.
>> 
>> Why wouldn't this be applicable for vsysreg.c? I can certainly 
>> fine-tune
>> the deviation, if needed
> 
> There the sole macro parameter is used in only one of the possible 
> ways,
> with ##, unless I'm overlooking something. Aiui it is mixed use which
> would need a deviation.

I see. In that case I'll restrict the deviation, thanks.

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)