[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 Mon, 25 Feb 2019, George Dunlap wrote:
> On Mon, Feb 25, 2019 at 11:42 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >
> > >>> On 22.02.19 at 22:33, <andrew.cooper3@xxxxxxxxxx> wrote:
> > > P.S. There is a solution here which could work, but IMO a better use of
> > > time and energy would be to get MISRA to update their rules to match
> > > this century, and stop getting in the way of compiler features intended
> > > to help the programmer avoid bugs.
> >
> > As much as I'm with you in desiring the compiler aid given to not get
> > undermined, I think this MISRA rule isn't in need of modernizing: It's
> > one thing for the compiler to help with in-range enumerators, and it's
> > another to demand that unintentional out-of-range ones don't cause
> > actual harm (like crashing your car into the next tree). This is even
> > more so that iirc there's no warning if you pass a plain integer into a
> > function whose parameter specifies an enum, or if you assign a plain
> > integer to an enum types variable.
> 
> FWIW I was thinking the same thing.

Jan described exactly the scenario Rule 16.4 attempts to protect us
from. FYI MISRAC explains the reasons behind each rule, this is why I
think it would be great for you (you as in the x86 and Arm maintainers
mainly) to have access to it so you can read the explanation by
yourselves.

Also, all the alternative suggestions about using complier features to
check switch statements are based on the fact that one can use those
compilers. I don't think we can/should/want to mandate which compilers
are used with the Xen codebase. We don't want to get into the situation
where the code is "safe" only when it is built with gcc.

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

 


Rackspace

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