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

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 2/26/19 1:47 PM, Jan Beulich wrote:
> > > > On 26.02.19 at 12:33, <andr2000@xxxxxxxxx> wrote:
> > 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
> I very much hope that I'm not going to be the only one to refuse
> to allow in any addition of such bogus "else" additions.
I don't expect such changes to be easily accepted.
> > 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.
> I guess then I have to ask for giving a complete picture of what
> other code uglifications are going to be proposed.
You can take a look at those rules which are partially available at [1]
>   If, to be MISRA-
> compliant, we have to turn all of our code into an unreadable
> mess,
This is why I think macros are not a good way forward
>   than I'm afraid I have to question whether we really want
> to go that route.
It depends on how you envision Xen's future and its appliances
>   We then may be better off stopping the whole
> exercise now, rather than after having done several initial steps
> already.
So, that was one of the goals of this series - to work out
approaches to solve the security certification issues
> Jan
[1] https://rules.sonarsource.com/c/RSPEC-126?search=misra

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