Re: [Xen-devel] [RFC PATCH 0/4] Add missing default labels to switch statements

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 2/26/19 1:20 PM, Jan Beulich wrote:
> > > > On 25.02.19 at 22:34, <julien.grall@xxxxxxx> wrote:
> > On 2/25/19 9:13 PM, Stefano Stabellini wrote:
> > > I think it is fine to exploit compiler specific checks when available.
> > > However, I don't think we should make any decisions on code correctness
> > > based on the compiler checks that we introduce.
> > >
> > > In other words, I think it is a good idea to use -Wswitch-enum if
> > > possible, but it is not a reason for not having default labels in place
> > > as suggested by 16.4. The code should be as correct and safe as
> > > possible, without requiring external compiler-specific checks.
> > As I said on an answer to Oleksandr, I am not against of having
> > "default" labels as long as they contain sensible actions.
> >
> > But this does not really address my point above regarding way to help
> > the review. Jan is against -Wswitch-enum, and I can understand his
> > point. So how do you deal with missing item?
> Just to clarify - I'm not entirely against the _optional_ use of
> -Wswitch-enum, but the added clutter needs to either be well justified
> (which so far it isn't), or conditionally hidden through some macro
> (where the main purpose of the macro really is to document why such
> otherwise pointless default labels are there in the first place).
Although I can agree that it might seem to be a good idea to hide
all those with a macro, but I am just thinking about other
cases which MISRA brings in. For example [1],
Rule 15.7 All if ... else if constructs shall be terminated with an else 
statement
So, we'll end up having lots of macros then which is obviously
not good. That said, I hope we can work out some common approach
not only to this issue, but how we deal with such in general.
> Jan
Thank you,
Oleksandr

[1] https://rules.sonarsource.com/c/RSPEC-126

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel