MISRA

MISRA is to a considerable extent making up for inadequacies or outright failings in C. Not so long ago somebody wrote on Hacker News that their safety-critical firmware is in Rust and for certification they were asked to provide some similar document to MISRA so, they just took the MISRA C doc and crossed out all the parts which were irrelevant for Rust, which, of course, is most of the MISRA C document. They're not kidding.

Let's take MISRA's rules 16.x - MISRA jealously guards copyright over their document and so I shan't recite any of it, but all of these 16.x rules are about C's switch statement. Now, a very naive programmer might say "Rust doesn't have switch so that's irrelevant" and of course that won't do at all, MISRA isn't worried about the specific word *switch*. But, when we look at Rust's match we see that it covers off almost all of MISRA's concerns, not as optional warnings, but as facets of the core language design.

Some of the 16.x rules are forbidding things no sane C programmer would do, and many would be surprised to discover are legal, such as trying to declare variables in one part of a switch and then use them in a different part even though presumably either declaration or usage won't happen when the statement is executed. Sure enough these things aren't legal Rust. But what's much nicer is that Rust also covers off some MISRA rules that apply to real C code that real programmers write. MISRA is worried about two things C programmers actually do that can hide terrible faults. Falling through, and inexhaustive matching. The C rules cover these by requiring break; religiously for each clause, and by requiring default religiously in every switch statement.

For Rust's match there is no fallthrough, so MISRA needn't forbid it, and all matches are exhaustive. If your match isn't exhaustive it won't compile. In fact Rust goes further, for API stability Rust provides #[non_exhaustive] enumerations which says, as the programmer of this data structure I don't promise I listed all the options yet, and so if you match on this, you must have a default case. For any other structures, you can't add a default case (it's redundant and causes a compiler error) if you in fact exhaustively handled every case. So, you get the benefit of MISRA's exhaustiveness *and* the benefit of common C compiler warnings for unnecessary default that often must be disabled for MISRA code.

One last 16.x rules stands out. MISRA really wants you to write the default case last, or first, but certainly not in the middle where you might lose it. It seems as first as though Rust has no similar rule, and we might need a lint here. But no! If you try to write your default case before other cases in Rust they are made redundant, and the compiler warns you this is a bad idea. You can ignore that warning, but MISRA elsewhere tells you to act on all the warnings if possible.

Now of course many MISRA directives (in particular) can't be trivially enforced by tools, human judgement is required. But even here Rust is often far ahead of C. For example MISRA wants you to document and test things, Rust's infrastructure automatically infers Markdown format documentation, one extra / in the comment above your function and it goes from merely commentary in the source code to HTML documentation that's automatically built for publication. If you write *example code* in that comment just in the ordinary way you would with Markdown, the test infrastructure automatically tries to run the code to check it actually works at the same time it runs any actual unit tests your wrote.