| Message ID | 20230907012203.1238090-1-sstabellini@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] docs/misra: add 14.3 | expand |
On 07.09.2023 03:22, Stefano Stabellini wrote: > @@ -385,6 +386,17 @@ maintainers if you want to suggest a change. > - A loop counter shall not have essentially floating type > - > > + * - `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_ > + - Required > + - Controlling expressions shall not be invariant > + - Due to the extensive usage of IS_ENABLED, sizeof compile-time > + checks, and other constructs that are detected as errors by MISRA > + C scanners, managing the configuration of a MISRA C scanner for > + this rule would be unmanageable. Thus, this rule is adopted with > + a project-wide deviation on if ?: and switch statements. Do we want to go as far as permitting this uniformly for all switch()? In my earlier reply I had included sizeof() for a reason. Also (nit) there's at least a comma missing after "if". To make clear it's keywords that are meant, maybe better use if() / switch()? Jan
On Thu, 7 Sep 2023, Jan Beulich wrote: > On 07.09.2023 03:22, Stefano Stabellini wrote: > > @@ -385,6 +386,17 @@ maintainers if you want to suggest a change. > > - A loop counter shall not have essentially floating type > > - > > > > + * - `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_ > > + - Required > > + - Controlling expressions shall not be invariant > > + - Due to the extensive usage of IS_ENABLED, sizeof compile-time > > + checks, and other constructs that are detected as errors by MISRA > > + C scanners, managing the configuration of a MISRA C scanner for > > + this rule would be unmanageable. Thus, this rule is adopted with > > + a project-wide deviation on if ?: and switch statements. > > Do we want to go as far as permitting this uniformly for all switch()? In > my earlier reply I had included sizeof() for a reason. I agree with you that it would be better to restrict it to only some switch uses, rather than all of them. But if we are going to restrict the deviation to switch(sizeof()), which I think is a good idea and I am in favor, wouldn't it be better to handle these cases as individual deviations? E.g. docs/misra/safe.json? I am assuming there are only few cases like that and adding it here makes the rule more complicated. I am happy either way but I wanted to provide that as an option. > Also (nit) there's at least a comma missing after "if". To make clear it's > keywords that are meant, maybe better use if() / switch()? OK I'll do that
On 07.09.2023 23:45, Stefano Stabellini wrote: > On Thu, 7 Sep 2023, Jan Beulich wrote: >> On 07.09.2023 03:22, Stefano Stabellini wrote: >>> @@ -385,6 +386,17 @@ maintainers if you want to suggest a change. >>> - A loop counter shall not have essentially floating type >>> - >>> >>> + * - `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_ >>> + - Required >>> + - Controlling expressions shall not be invariant >>> + - Due to the extensive usage of IS_ENABLED, sizeof compile-time >>> + checks, and other constructs that are detected as errors by MISRA >>> + C scanners, managing the configuration of a MISRA C scanner for >>> + this rule would be unmanageable. Thus, this rule is adopted with >>> + a project-wide deviation on if ?: and switch statements. >> >> Do we want to go as far as permitting this uniformly for all switch()? In >> my earlier reply I had included sizeof() for a reason. > > I agree with you that it would be better to restrict it to only some > switch uses, rather than all of them. > > But if we are going to restrict the deviation to switch(sizeof()), which > I think is a good idea and I am in favor, wouldn't it be better to > handle these cases as individual deviations? E.g. docs/misra/safe.json? > I am assuming there are only few cases like that and adding it here > makes the rule more complicated. Personally I think it wants to be both anyway. For one, anything written here still needs respective SAF annotations for scanners to be uniformly aware (dealing with deviations in just the Eclair configuration is imo dubious). And then my general view is that by stating patterns here we make clear that we tolerate new instances of such constructs, whereas in other cases we'd be aiming at no deviations in new code. Jan
On 07/09/2023 23:45, Stefano Stabellini wrote: > On Thu, 7 Sep 2023, Jan Beulich wrote: >> On 07.09.2023 03:22, Stefano Stabellini wrote: >> > @@ -385,6 +386,17 @@ maintainers if you want to suggest a change. >> > - A loop counter shall not have essentially floating type >> > - >> > >> > + * - `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_ >> > + - Required >> > + - Controlling expressions shall not be invariant >> > + - Due to the extensive usage of IS_ENABLED, sizeof compile-time >> > + checks, and other constructs that are detected as errors by MISRA >> > + C scanners, managing the configuration of a MISRA C scanner for >> > + this rule would be unmanageable. Thus, this rule is adopted with >> > + a project-wide deviation on if ?: and switch statements. >> >> Do we want to go as far as permitting this uniformly for all switch()? >> In >> my earlier reply I had included sizeof() for a reason. > > I agree with you that it would be better to restrict it to only some > switch uses, rather than all of them. > > But if we are going to restrict the deviation to switch(sizeof()), > which > I think is a good idea and I am in favor, wouldn't it be better to > handle these cases as individual deviations? E.g. docs/misra/safe.json? > I am assuming there are only few cases like that and adding it here > makes the rule more complicated. > > I am happy either way but I wanted to provide that as an option. > > It's also worth considering the magnitude of required SAF comments when making this choice. In this case, from a cursory glance at the present violations, it seems that there are maybe a handful of switches inside macros, so they shouldn't be problematic to deal with.
On Fri, 8 Sep 2023, Nicola Vetrini wrote: > On 07/09/2023 23:45, Stefano Stabellini wrote: > > On Thu, 7 Sep 2023, Jan Beulich wrote: > > > On 07.09.2023 03:22, Stefano Stabellini wrote: > > > > @@ -385,6 +386,17 @@ maintainers if you want to suggest a change. > > > > - A loop counter shall not have essentially floating type > > > > - > > > > > > > > + * - `Rule 14.3 > > > <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_ > > > > + - Required > > > > + - Controlling expressions shall not be invariant > > > > + - Due to the extensive usage of IS_ENABLED, sizeof compile-time > > > > + checks, and other constructs that are detected as errors by > > > MISRA > > > > + C scanners, managing the configuration of a MISRA C scanner for > > > > + this rule would be unmanageable. Thus, this rule is adopted with > > > > + a project-wide deviation on if ?: and switch statements. > > > > > > Do we want to go as far as permitting this uniformly for all switch()? In > > > my earlier reply I had included sizeof() for a reason. > > > > I agree with you that it would be better to restrict it to only some > > switch uses, rather than all of them. > > > > But if we are going to restrict the deviation to switch(sizeof()), which > > I think is a good idea and I am in favor, wouldn't it be better to > > handle these cases as individual deviations? E.g. docs/misra/safe.json? > > I am assuming there are only few cases like that and adding it here > > makes the rule more complicated. > > > > I am happy either way but I wanted to provide that as an option. > > > > > > It's also worth considering the magnitude of required SAF comments when making > this choice. > In this case, from a cursory glance at the present violations, it seems that > there are maybe a > handful of switches inside macros, so they shouldn't be problematic to deal > with. That's what I thought as well and why I suggested to only deal with them in safe.json. However, it doesn't cost us anything to be extra clear, so I'll send an updated patch with extra clarity.
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index 34916e266a..3d8d1633a4 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -234,7 +234,8 @@ maintainers if you want to suggest a change. * - `Rule 8.2 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_02.c>`_ - Required - Function types shall be in prototype form with named parameters - - + - Clarification: both function and function pointers types shall + have named parameters. * - `Rule 8.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_08_03.c>`_ - Required @@ -385,6 +386,17 @@ maintainers if you want to suggest a change. - A loop counter shall not have essentially floating type - + * - `Rule 14.3 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_14_03.c>`_ + - Required + - Controlling expressions shall not be invariant + - Due to the extensive usage of IS_ENABLED, sizeof compile-time + checks, and other constructs that are detected as errors by MISRA + C scanners, managing the configuration of a MISRA C scanner for + this rule would be unmanageable. Thus, this rule is adopted with + a project-wide deviation on if ?: and switch statements. + + while(0) and while(1) and alike are allowed. + * - `Rule 16.7 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_16_07.c>`_ - Required - A switch-expression shall not have essentially Boolean type