[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v2] automation/eclair: add deviations for MISRA C:2012 Rule 16.4
On 24.04.2024 11:00, Federico Serafini wrote: > On 24/04/24 10:30, Jan Beulich wrote: >> On 24.04.2024 10:25, Federico Serafini wrote: >>> Update ECLAIR configuration to take into account the deviations >>> agreed during MISRA meetings for Rule 16.4. >>> >>> Signed-off-by: Federico Serafini <federico.serafini@xxxxxxxxxxx> >>> --- >>> automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++ >>> docs/misra/deviations.rst | 13 +++++++++++++ >>> 2 files changed, 21 insertions(+) >>> >> >> So what has changed here from v1? It looks all the same to me, with it still >> remaining unclear what exactly ... >> >>> --- a/docs/misra/deviations.rst >>> +++ b/docs/misra/deviations.rst >>> @@ -334,6 +334,19 @@ Deviations related to MISRA C:2012 Rules: >>> - /\* Fallthrough \*/ >>> - /\* Fallthrough. \*/ >>> >>> + * - R16.4 >>> + - Switch statements having a controlling expression of enum type >>> + deliberately do not have a default case: gcc -Wall enables -Wswitch >>> + which warns (and breaks the build as we use -Werror) if one of the >>> enum >>> + labels is missing from the switch. >>> + - Tagged as `deliberate` for ECLAIR. >>> + >>> + * - R16.4 >>> + - A switch statement with a single switch clause and no default label >>> may >>> + be used in place of an equivalent if statement if it is considered >>> to >>> + improve readability. >>> + - Tagged as `deliberate` for ECLAIR. >>> + >>> * - R16.6 >>> - A switch statement with a single switch clause and no default >>> label may >>> be used in place of an equivalent if statement if it is considered >>> to >> >> ... a "switch clause" is. > > I would define a switch clause as: > "the non-empy list of statements which follows a non-empty list of > case/default labels". > If you agree, I will place it near the occurrences of the term > "switch clause". I'm afraid I don't (quite) agree, and I had hoped that I would have got my point across that such a definition wants to be in terms used by the C spec. "statement" is too broad here, as that in particular includes "labeled-statement" as well. Ordinary labels are (aiui) okay to have in there, so entirely excluding "labeled-statement" wouldn't be quite right either. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |