Re: [XEN PATCH] xen: add explicit comment to identify notifier patterns

[Federico Serafini <federico.serafini@xxxxxxxxxxx>]

On 17/06/24 12:03, Jan Beulich wrote:
> On 17.06.2024 11:49, Federico Serafini wrote:
> > MISRA C Rule 16.4 states that every `switch' statement shall have a
> > `default' label" and a statement or a comment prior to the
> > terminating break statement.
> >
> > This patch addresses some violations of the rule related to the
> > "notifier pattern": a frequently-used pattern whereby only a few values
> > are handled by the switch statement and nothing should be done for
> > others (nothing to do in the default case).
> >
> > No functional change.
> >
> > Signed-off-by: Federico Serafini <federico.serafini@xxxxxxxxxxx>
> I guess I shouldn't outright NAK this, but I certainly won't ack it. This
> is precisely the purely mechanical change that in earlier discussions some
> (including me) have indicated isn't going to help safety. However, if
> others want to ack something purely mechanical like this, then my minimal
> requirement would be that somewhere it is spelled out what falls under
>
> > ---
> >   xen/arch/arm/cpuerrata.c            | 1 +
> >   xen/arch/arm/gic.c                  | 1 +
> >   xen/arch/arm/irq.c                  | 4 ++++
> giv-v3-lpi.c has a similar instance, yet you don't adjust that. This may
> be because that possibly is the one where it was previously indicated that
> it may in fact be a mistake that the dying/dead case isn't handled, but
> then at the very least I'd have expected that you explicitly mention cases
> where the adjustment is (deliberately) not made.
I did the changes accordingly to the instruction in docs/misra/rules.rst
for Rule 16.4 and I touched only the files having an unjustified
violations of the rule.
The violation triggered by gic-v3-lpi.c is currently deviated with the
following justification: "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."
However, I agree with you that also gic-v3.c should be consistent with
the other.

--
Federico Serafini, M.Sc.

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