Re: [XEN PATCH v2] automation/eclair: extend existing deviations of MISRA C:2012 Rule 16.3

[Federico Serafini <federico.serafini@xxxxxxxxxxx>]

On 13/06/24 10:16, Jan Beulich wrote:
> On 13.06.2024 08:38, Federico Serafini wrote:
> > Update ECLAIR configuration to deviate more cases where an
> > unintentional fallthrough cannot happen.
> >
> > Add Rule 16.3 to the monitored set and tag it as clean for arm.
> >
> > Signed-off-by: Federico Serafini <federico.serafini@xxxxxxxxxxx>
> > ---
> >   
> >      * - R16.3
> > -     - Switch clauses ending with continue, goto, return statements are safe.
> > +     - Statements that change the control flow (i.e., break, continue, goto,
> > +       return) and calls to functions that do not return the control back are
> > +       \"allowed terminal statements\".
> >        - Tagged as `safe` for ECLAIR.
> >   
> >      * - R16.3
> > -     - Switch clauses ending with a call to a function that does not give
> > -       the control back (i.e., a function with attribute noreturn) are safe.
> > +     - An if-else statement having both branches ending with one of the allowed
> > +       terminal statemets is itself an allowed terminal statements.
> Nit: "... terminal statements is ... terminal statement."
Thanks.

> > +     - Tagged as `safe` for ECLAIR.
> > +
> > +   * - R16.3
> > +     - An if-else statement having an always true condition and the true
> > +       branch ending with an allowed terminal statement is itself an allowed
> > +       terminal statement.
> > +     - Tagged as `safe` for ECLAIR.
> > +
> > +   * - R16.3
> > +     - Switch clauses ending with a statement expression which, in turn, ends
> > +       with an allowed terminal statement are safe (e.g., the expansion of
> > +       generate_exception()).
> > +     - Tagged as `safe` for ECLAIR.
> > +
> > +   * - R16.3
> > +     - Switch clauses ending with a do-while-false which, in turn, ends with an
> Maybe more precisely "the body of which"?
Will do.

> > +       allowed terminal statement are safe (e.g., PARSE_ERR_RET()).
> > +       Being ASSERT_UNREACHABLE() a construct that is effective in debug builds
> > +       only, it is not considered as an allowed terminal statement, despite its
> > +       definition.
> DYM despite its name? Its definition is what specifically renders it unsuitable
> for release builds.
In debug builds, ASSERT_UNREACHABLE() expands to a do-while-false
the body of which ends with __builtin_unreachable() which is a builtin
marked as "noreturn" and thus considered as one of the "allowed
terminal statements".
As a result, ASSERT_UNREACHABLE() will be considered as an
"allowed terminal statement" as well, which is something we want to
avoid.

> Also I think the sentence wants to either start "ASSERT_UNREACHABLE() being a
> ..." or wants to be re-ordered to e.g. "Being a construct that is effective in
> debug builds only, ASSERT_UNREACHABLE() is not considered ..."
>
> Jan
--
Federico Serafini, M.Sc.

Software Engineer, BUGSENG (http://bugseng.com)