[XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4

[XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4

[Nicola Vetrini]

Rule 20.4 states: "A macro shall not be defined with the same name
as a keyword".

Defining this macro with the same name as the inline keyword
allows for additionally checking that out-of-lined static inline
functions end up in the correct section while minimizing churn and
has a positive impact on the overall safety. See [1] for additional
context on the motivation of this deviation.

No functional change.

[1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- Rephrased SAF comment to be more general and added exact motivation
  for the redefinition of "inline" in deviation.rst.
---
 docs/misra/deviations.rst  | 6 ++++++
 docs/misra/safe.json       | 8 ++++++++
 xen/include/xen/compiler.h | 1 +
 3 files changed, 15 insertions(+)

diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 123c78e20a01..f8b40dd1e461 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules:
          - /\* Fallthrough \*/
          - /\* Fallthrough. \*/
 
+   * - R20.4
+     -  The override of the keyword \"inline\" in xen/compiler.h is present so
+        that section contents checks pass when the compiler chooses not to
+        inline a particular function.
+     - Comment-based deviation.
+
    * - R20.7
      - Code violating Rule 20.7 is safe when macro parameters are used:
        (1) as function arguments;
diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 952324f85cf9..d361d0e65ceb 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -28,6 +28,14 @@
         },
         {
             "id": "SAF-3-safe",
+            "analyser": {
+                "eclair": "MC3R1.R20.4"
+            },
+            "name": "MC3R1.R20.4: allow the definition of a macro with the same name as a keyword in some special cases",
+            "text": "The definition of a macro with the same name as a keyword can be useful in certain configurations to improve the guarantees that can be provided by Xen. See docs/misra/deviations.rst for a precise rationale for all such cases."
+        },
+        {
+            "id": "SAF-4-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index 16d554f2a593..fc87a2edad7f 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -82,6 +82,7 @@
  * inline functions not expanded inline get placed in .init.text.
  */
 #include <xen/init.h>
+/* SAF-3-safe MISRA C Rule 20.4: allow section checks to pass when not inlined */
 #define inline inline __init
 #endif
 
-- 
2.34.1

Re: [XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4

[Jan Beulich]

On 12.03.2024 12:13, Nicola Vetrini wrote:
> Rule 20.4 states: "A macro shall not be defined with the same name
> as a keyword".
> 
> Defining this macro with the same name as the inline keyword
> allows for additionally checking that out-of-lined static inline
> functions end up in the correct section while minimizing churn and
> has a positive impact on the overall safety. See [1] for additional
> context on the motivation of this deviation.
> 
> No functional change.
> 
> [1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Acked-by: Jan Beulich <jbeulich@suse.com>
with ...

> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules:
>           - /\* Fallthrough \*/
>           - /\* Fallthrough. \*/
>  
> +   * - R20.4
> +     -  The override of the keyword \"inline\" in xen/compiler.h is present so
> +        that section contents checks pass when the compiler chooses not to
> +        inline a particular function.

... padding (1st line of this bullet point) and indentation (2nd and 3rd
lines) adjusted to what's used elsewhere, including e.g ...

> +     - Comment-based deviation.
> +
>     * - R20.7
>       - Code violating Rule 20.7 is safe when macro parameters are used:
>         (1) as function arguments;

... here. Happy to do so while committing.

Jan

Re: [XEN PATCH v2] xen/compiler: deviate the inline macro for MISRA C Rule 20.4

[Nicola Vetrini]

On 2024-03-12 12:25, Jan Beulich wrote:
> On 12.03.2024 12:13, Nicola Vetrini wrote:
>> Rule 20.4 states: "A macro shall not be defined with the same name
>> as a keyword".
>> 
>> Defining this macro with the same name as the inline keyword
>> allows for additionally checking that out-of-lined static inline
>> functions end up in the correct section while minimizing churn and
>> has a positive impact on the overall safety. See [1] for additional
>> context on the motivation of this deviation.
>> 
>> No functional change.
>> 
>> [1] 
>> https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> with ...
> 
>> --- a/docs/misra/deviations.rst
>> +++ b/docs/misra/deviations.rst
>> @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules:
>>           - /\* Fallthrough \*/
>>           - /\* Fallthrough. \*/
>> 
>> +   * - R20.4
>> +     -  The override of the keyword \"inline\" in xen/compiler.h is 
>> present so
>> +        that section contents checks pass when the compiler chooses 
>> not to
>> +        inline a particular function.
> 
> ... padding (1st line of this bullet point) and indentation (2nd and 
> 3rd
> lines) adjusted to what's used elsewhere, including e.g ...
> 

Yeah, sorry.

>> +     - Comment-based deviation.
>> +
>>     * - R20.7
>>       - Code violating Rule 20.7 is safe when macro parameters are 
>> used:
>>         (1) as function arguments;
> 
> ... here. Happy to do so while committing.
> 

Thanks,

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