I had been planning on talking about MISRA C compliance in a month or two from now. However, in the comments section of my recent post about bitfields, Anand posed the following question:
However I am writing to ask your opinion about MISRA C compliance. This is the first time a client company has asked us for MISRA C compliance and I am not quite sure where to start. I started reading the guidelines from the web, however soon realised that its an enormous task and I would never get through all of them. So what I would like to know from you is how realistic is it to expect to comply with all the guidelines? Since my compiled code size is less than 2KB so should we even bother with MISRA C compliance?
Your valuable insights would be highly appreciated
I first gave my thoughts about MISRA C in an article published in 2002 in Embedded Systems Programming magazine (now Embedded Systems Design). Looking back over the article, I don’t see anything in it that I disagree with now. However, there are certainly some things that I’d add, having attempted to adhere to the MISRA guidelines in several large projects. After I have given my thoughts, I’ll try and address Anand’s questions.
I’ll start by noting that since I wrote the aforementioned article, MISRA released a second edition of their guidelines in 2004. The second edition was a major revision, and attempted to address many of the ambiguities in the 1998 version. As such, if someone is asking for MISRA compliance, they usually mean the 2004 rules; however it would behoove you to check!
Most of the MISRA rules can be checked via static analysis (i.e. by a compiler like tool) and indeed many more compilers now come with a MISRA checking option. Thus for those of you that are using such a compiler, conformance to most of the rules may be checked by simply using the correct compiler switch. For those of you that don’t have such a compiler, a great alternative is my favorite tool – PC-Lint from Gimpel – which brings me nicely to the main point I wish to make. MISRA attempts to protect you from the darkest, nastiest corners of the C language – which is exactly what PC-Lint attempts to do as well. However, MISRA C attempts to do it by banning various constructs, whereas PC-Lint attempts to detect and inform you when you are using a construct in a potentially dangerous way. To put it another way, MISRA treats you like a child and PC-Lint treats you like an adult. As a result, I’ll take code that is ‘Lint free’ over code that is ‘MISRA compliant’ any day. I’d also add that making code Lint free is often a lot more challenging than making it MISRA compliant.
Now does this mean that I think the MISRA rules are not worthwhile? Absolutely not! Indeed the vast majority of the rules are pretty much good programming practice in a codified form. For example, rule 2.2. states: “Source code shall only use ISO9899:1990 ‘C’ style comments”. Now regardless of whether you agree with this rule or not, it’s my opinion that source code that contains C style comments and C++ style comments reflects a lack of discipline on the author’s behalf. Thus I like this rule – and I adhere to it.
Where I start to run into problems with MISRA are rules such as 20.6 “The macro offsetof in stddef.h shall not be used”. I wrote an article in 2004 for Embedded Systems Programming magazine entitled “Learn a new trick with the offsetof() macro”. The examples I give in the article are elegant and robust solutions to certain common classes of problems in embedded systems. Solving these problems without using the offsetof() macro is hard and /or tedious and / or dangerous. In short the medicine prescribed by MISRA is worse than the supposed disease.
Putting this all together, my feelings on MISRA are as follows.
- It’s intentions are excellent – and I wholeheartedly support them.
- Most of its rules are really good.
- There are times when I just have to say – sorry your attempts to make my code ‘safer’ are actually having the opposite effect and so as an experienced embedded systems engineer I’m choosing to ignore the rule in the interest of making a safer product. Note that I don’t do this on a whim!
Now clearly, when it comes to my third point, I can certainly be accused of hubris. However, at the end of the day my clients typically hire me for my experience / knowledge and not for my ability to follow a rule book.
As a final note, I must say that I think the MISRA committee has overall done a very fine job. Trying to come up with a set of rules for the vastly disparate embedded systems industry (I know they are only really aimed at the car industry) is essentially an impossible task.
So with that all of the above as a preamble, I think I can address Anand’s questions.
Where to Start?
Order a copy of the guidelines from MISRA. You can get an electronic copy for £10 (about $15). If you are using a C compiler that has a MISRA checking switch, then turn it on. If not buy a copy of PC-Lint. If you are not already using PC-Lint then you should be. It will be the best $389 you ever spent.
Take a snapshot of your code base in your version control system before starting.
The first time you check your code for compliance, you will undoubtedly get an enormous number of errors. However, I think you will find that half a dozen rules are creating 90% of the problems. Thus you should be able to knock the error count down fairly quickly to something manageable. At that point you will be in to some of the tougher problems. My recommendation is not to blow off the MISRA errors, but rather to understand why MISRA thinks your constructs are unsafe. Only once you are convinced that your particular instance is indeed safe should you choose to ignore the violation.
Is it worth it for 2K of object code?
Yes – and no. With an executable image of 2K, the chances are most of your code is very tightly tied to the hardware. In my experience, the closer you get to the hardware, the harder it is to achieve MISRA compliance, simply because interaction with the hardware typically relies upon extensions to standard C – and these extensions violate MISRA rule 1.1. Thus you have no hope of making your code compliant, literally starting with the first rule. (The MISRA committee aren’t stupid, and so they have a formal method for allowing you to waive certain rules – and this is a clear example of why it’s necessary. However, it’s a tough way to start out). Does this mean that the exercise is pointless though? Probably not, as at the end of the day you’ll probably have cleaner, more portable, more easily maintained code. However, I seriously doubt that it will be compliant.
Finally, I’ll answer a question that you didn’t ask. What should I say to a client that asks for MISRA compliance? Well the first thing to determine is whether compliance is desired or required. If it’s the former, then what they are probably asking for is work that conforms to industry best practices. In which case what I normally do is explain to them that the code I deliver will be Lint free – and that this is a far higher hurdle to cross than MISRA compliance. If however MISRA compliance is a must, then you have no option other than to bite the bullet and get to work. It would probably make sense to retain a consultant for a day or two to help you get up to speed quickly.