[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
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
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
So, that was one of the goals of this series - to work out
approaches to solve the security certification issues

[1] https://rules.sonarsource.com/c/RSPEC-126?search=misra

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.