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.seraf...@bugseng.com>
>>> ---
>>>   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

Reply via email to