On Mon, 25 Feb 2019, George Dunlap wrote: > On Mon, Feb 25, 2019 at 11:42 AM Jan Beulich <jbeul...@suse.com> wrote: > > > > >>> On 22.02.19 at 22:33, <andrew.coop...@citrix.com> 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel