[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: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.


Thank you,

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

Xen-devel mailing list



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