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.1
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. > + { > + "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 - 2024 Red Hat, Inc.