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

[Oleksandr Andrushchenko <andr2000@xxxxxxxxx>]

On 2/25/19 1:47 PM, Julien Grall wrote:
> Hi,
>
> On 25/02/2019 10:11, Oleksandr Andrushchenko wrote:
> > On 2/23/19 12:08 AM, Julien Grall wrote:
> > > On 22/02/2019 21:00, Stefano Stabellini wrote:
> > > > On Fri, 22 Feb 2019, Julien Grall wrote:
> > > > > > > > BTW, I checked the series with -Wswitch-default:
> > > > > > > > -Wswitch-default
> > > > As 16.4 clearly state, even a simple comment would be enough to 
> > > > address
> > > > the rule. We just need to explain why a default label is not needed.
> > > > Such as:
> > > >
> > > >     default:
> > > >     /* unreachable because blah and blah */
> > > ... as we already have defensive code. Indeed, in most of the switch we
> > > deal with potential issue by initializing the variable before the
> > > switch. If you look at the first patch, a lot of "default: break;" is
> > > introduced. So what's our benefits? How this code is more defensive 
> > > than
> > > what we currently have?
> > ...and if you remove those initialized variables and forget
> > to update the switch with default? Or change the initial value
> > the way your previous switch assumptions do not work anymore?
> > I am not trying to defend MISRA here, but things change and we all
> > make mistakes. This is why defensive programming
> I am not totally against using default label. However, how is the 
> following code is defensive?
> default:
>    break;
>
> This heavily relies on the code surrounding if dealing correctly with 
> the error and will never change. It feels to me we are only trying to 
> make MISRA happy.
> If we were writing defensive code, then you would definitely not have 
> empty default and would at least contain an ASSERT_UNREACHABLE or 
> error handling.
> But then, you still rely on the default case to do the right thing if 
> there was an error. I fail to understand how this is better than what 
> we currently have.
I do agree on this. And will say it again that we are trying to work out an
acceptable approach that (if even possible) both satisfies the community by
not bringing artificial constructs like empty defaults and still satisfies
the corresponding certification requirements.
> > > Furthermore, how this is going to help us (thanks to -Wswitch) if an
> > > enumerate is extended and we miss a case that the compiler don't notice
> > > anymore?
> > And if the switch's index is not an enumeration, but a plain integer...?
> We have to differentiate enum vs plain integer.
>
> For enum, a compiler supporting -Wswitch can helps us to catch when we 
> forgot to handle a element of the enum. The default case defeats 
> -Wswitch. Yet having a default could protect us against code error. It 
> looks like that GCC have an option -Wswitch-enum that could help us. 
> The option will similar to -Wswitch except it will warn even when 
> there are a default case. I am curious to see if we can use it 
> reliably in Xen.
> For plain integer, we indeed need to have a *sensible* default case.
Ok, so at least with enums we can use -Wswitch-xxx approach, but I 
cannot tell
if this is enough to make MISRA happy. Probably we will need to document all
such cases, so we have a dedicated justification for every single place 
we do not want
defaults mess.
> Cheers,

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