New updates improve an already excellent MISRA

MISRA is probably the most widely-used firmware standard (Motor Industry Software Reliability Association). Alas, only a tiny fraction of us use any standard religiously.

Though MISRA was founded by companies with an automotive bent it is now used by organizations all across the firmware landscape. With good reason, too. The 140-odd rules are designed to improve the quality of embedded code. I think that MISRA doesn't go far enough; it's silent, for example, about stylistic issues. But MISRA is an excellent starting point and every embedded developer should be familiar with the standard. The current, 2012, version is available as a .PDF at http://misra.org.uk/ for £15.

Directive 4.14 requires that all values from external sources be checked for validity. Duh! Almost five decades ago when I first started programming in Fortran we were told to check the goesintos and goesoutas. Users will type anything in, attackers will exploit buffer problems, and external libraries may do unexpected things. Yet an astonishing amount of the code I read blithely assumes the data will be just fine.

Rule 21.7 restricts the use of functions in string.h to ensure references don't exceed the size of the variable being worked on. Again, a no-brainer, but the rules are meant as checks on our code. To claim MISRA compliance you have to ensure your code follows the rules.

22.8 requires one to set errno to zero before calling any errno-setting function (e.g., fgetpos). Why? These functions change errno only if an error is detected. Otherwise errno is unmodified. And the next rule requires errno be tested against zero after calling an errno-setting function.

In addition to MISRA's new amendment 1, they've just released addendum 2 which is a short .PDF that maps their rules against those propagated by C Secure. Bottom line: MISRA's rules cover almost everything in C Secure.

My take on MISRA is that it should be a starting place, a least common denominator. Add the C Secure rules that MISRA is weak on. Bolt on stylistic rules. Couple all of that with what you learn about mistakes endemic to your team, or what you read about in the literature.

I'm a tool guy, and believe that everything that can be automated, should be automated. Don't tie up expensive developers with brain-dead tasks that a machine can do. Use a tool that checks your code against the standard your company comes up with. I'm most familiar with LDRA's tool chain (http://www.ldra.com). They tell me that their compliance checker already incorporates all of the new rules in MISRA Amendment 1 (with the caveat that some rules simply cannot be checked automatically). And, LDRA's tool can be configured to check any decidable rule. Want to add some rules from the JSF coding standard? It's just a matter of clicking on those you want and ignoring the others.

Published May, 2016

There are a lot of standards around. The aforementioned JSF document is maintained by the Feds and – unsurprisingly! – the link is broken. But you can get it here: http://www.stroustrup.com/JSF-AV-rules.pdf. Or there's JPL's (http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf). That was used for Mars Curiosity, the insanely-successful mission that has been exploring the planet for almost four years. A software success story for sure.
 
For most of us MISRA is a logical starting point. It's widely-used. More and more commercial packages are compliant. Comply today, and if you'll ever, maybe years in the future, need to claim compliance for regulatory or marketing reasons, the work will already be done; no recoding will be required.