docs/misra/safe.json | 8 ++++++++ xen/include/xen/compiler.h | 1 + 2 files changed, 9 insertions(+)
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>
---
docs/misra/safe.json | 8 ++++++++
xen/include/xen/compiler.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 952324f85cf9..a2bbacddf06a 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 augmentation of the inline keyword in some build configurations",
+ "text": "The definition of this macro named inline allows further checking in some build configurations that certain symbols end up in the right sections."
+ },
+ {
+ "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..e3d9f9fb8e4b 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: define the inline macro to perform checks */
#define inline inline __init
#endif
--
2.34.1On 08.03.2024 09:10, 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>
> ---
> docs/misra/safe.json | 8 ++++++++
> xen/include/xen/compiler.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/docs/misra/safe.json b/docs/misra/safe.json
> index 952324f85cf9..a2bbacddf06a 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 augmentation of the inline keyword in some build configurations",
> + "text": "The definition of this macro named inline allows further checking in some build configurations that certain symbols end up in the right sections."
> + },
With this wording the ID isn't going to be re-usable anywhere else. Even
if the exact same reasoning would apply.
> + {
> + "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..e3d9f9fb8e4b 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: define the inline macro to perform checks */
> #define inline inline __init
> #endif
I don't think the definition is "to perform checks"; it's rather to make
sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override
"inline" for section contents checks to pass when the compiler chooses
not to inline a particular function' perhaps? Albeit that's getting
long-ish, I fear.
Jan
On 2024-03-11 08:32, Jan Beulich wrote:
> On 08.03.2024 09:10, 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>
>> ---
>> docs/misra/safe.json | 8 ++++++++
>> xen/include/xen/compiler.h | 1 +
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/docs/misra/safe.json b/docs/misra/safe.json
>> index 952324f85cf9..a2bbacddf06a 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 augmentation of the
>> inline keyword in some build configurations",
>> + "text": "The definition of this macro named inline allows
>> further checking in some build configurations that certain symbols end
>> up in the right sections."
>> + },
>
> With this wording the ID isn't going to be re-usable anywhere else.
> Even
> if the exact same reasoning would apply.
>
What about
"name": "MC3R1.R20.4: allow the definition of a macro with the same name
as a keyword in some special cases"
and
"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.
and then..
>> + {
>> + "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..e3d9f9fb8e4b 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: define the inline macro to perform
>> checks */
>> #define inline inline __init
>> #endif
>
> I don't think the definition is "to perform checks"; it's rather to
> make
> sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override
> "inline" for section contents checks to pass when the compiler chooses
> not to inline a particular function' perhaps? Albeit that's getting
> long-ish, I fear.
put this message in deviations.rst
>
> Jan
is this proposal more appealing?
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 11.03.2024 16:48, Nicola Vetrini wrote:
> On 2024-03-11 08:32, Jan Beulich wrote:
>> On 08.03.2024 09:10, Nicola Vetrini wrote:
>>> --- 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 augmentation of the
>>> inline keyword in some build configurations",
>>> + "text": "The definition of this macro named inline allows
>>> further checking in some build configurations that certain symbols end
>>> up in the right sections."
>>> + },
>>
>> With this wording the ID isn't going to be re-usable anywhere else.
>> Even
>> if the exact same reasoning would apply.
>>
>
> What about
>
> "name": "MC3R1.R20.4: allow the definition of a macro with the same name
> as a keyword in some special cases"
>
> and
>
> "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.
>
> and then..
>
>>> + {
>>> + "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..e3d9f9fb8e4b 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: define the inline macro to perform
>>> checks */
>>> #define inline inline __init
>>> #endif
>>
>> I don't think the definition is "to perform checks"; it's rather to
>> make
>> sure checking elsewhere wouldn't (seemingly) randomly fail. 'Override
>> "inline" for section contents checks to pass when the compiler chooses
>> not to inline a particular function' perhaps? Albeit that's getting
>> long-ish, I fear.
>
> put this message in deviations.rst
>
> is this proposal more appealing?
I think so, yes.
Jan
On Fri, 8 Mar 2024, 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> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
© 2016 - 2026 Red Hat, Inc.