On Tue, 22 Aug 2023, Jan Beulich wrote:
> (re-adding xen-devel@)
>
> On 22.08.2023 17:09, Nicola Vetrini wrote:
> >
> >>>> + - Switch with a controlling value incompatible with labeled
> >>>> + statements
> >>>
> >>> What does this mean?
> >>
> >> I am not certain about this one actually. It could be when we have:
> >>
> >> switch (var) {
> >> case 1:
> >> something();
> >> break;
> >> case 2:
> >> something();
> >> break;
> >> }
> >>
> >> and var could be 3 in theory?
> >>
> >> Nicola, please confirm.
> >>
> >>
> >
> > This one is about case labels that are statically determined not to be
> > reachable (and hence
> > saying that the code under that label is unreachable is not inaccurate)
> > because the
> > controlling expression of the switch statement can never have such
> > value. An example below:
> >
> > $ cat p.c
> > int f(void) {
> > char c;
> > switch (c) {
> > case 260:
> > return 260;
> > case 4:
> > return 4;
> > }
> > }
> >
> > $ eclair_env -enable=MC3.R2.1,B.REPORT.TXT -- gcc -c p.c
> > violation for rule MC3.R2.1: (required) A project shall not contain
> > unreachable code. (untagged)
> > p.c:3.3-3.8: Loc #1 [culprit: `switch' statement has a controlling value
> > incompatible with labeled statement]
> > switch (c) {
> > <~~~~>
> > p.c:5.14-5.16: Loc #2 [evidence: integer literal is unreachable]
> > return 260;
> > <~>
> >
> > This is also true for things like
> >
> > switch(sizeof(int)) {
> > case 2:
> > ...
> > case 4:
> > ...
> > }
>
> Ah yes, we certainly have quite a few of those. Not sure how to best
> describe such for the doc, but what was suggested (still visible at
> the top) doesn't get this across, I'm afraid,
What about: "switch with a controlling value statically determined not
to match one or more case statements"
I'll send it as part of a separate new patch to update rules.rst for 2.1
