embedded software boot camp

Is MISRA compliance worthwhile?

Wednesday, October 7th, 2009 by Nigel Jones

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.

  1. It’s intentions are excellent – and I wholeheartedly support them.
  2. Most of its rules are really good.
  3. 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.

Then What?
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.


Tags: , ,

11 Responses to “Is MISRA compliance worthwhile?”

  1. Tom Harris says:

    Your guidance about how to apply — and make exceptions to — a coding standard, and how to use PC-lint, make sense to me.But I don't understand why you describe PC-lint as an alternative to MISRA compliance. Gimpel Software provides a PC-lint configuration file (au-misra2.lnt) which maps as many MISRA rules as possible to PC-lint rules, but lets you both subtract MISRA rules, and add additional PC-lint rules directly.Could you clarify what you meant?

  2. Nigel Jones says:

    If you turn MISRA checking on with PC-Lint, then it obviously checks a superset of the MISRA rules. However without MISRA checking turned on, then it uses a set of rules that are of course a little different. I guess the way I see it is this (where in the description below, Lint is configured so as to not perform MISRA checking):Code can be 'Lint free' but not 'MISRA free'. Code may be 'MISRA free' but not 'Lint free'. Clearly it can also be both 'Lint free' and 'MISRA free'. Thus the question is, of these three possibilities, which ensures the best code quality? I think many folks would be tempted to say both 'Lint & MISRA free'. I guess my point is that I don't think that's always the case – and that Lint free is sometimes better.

  3. Michael says:

    I agree that PC-Lint is good value for money but it would not be my first choice for checking MISRA compliance especially if compliance was mandated by a customer. Firstly the number of rules supported is low comparative to other tools [about 80% of the mandatory rules are “supported”], and secondly, PC-Lint seems to fail to detect non-compliance for some “supported” rules when checked against the MISRA Exemplar suite. For example, rules 5.6 and 5.7. Note this was my conclusion when testing with PC Lint 8.00v and the results have not been independently confirmed. My understanding is that existing PC-Lint checks have been mapped against MISRA rules rather than adding new checks and it would seem to have been less than precise.

  4. Nigel Jones says:

    That's very interesting to know Michael. Although I'm a huge fan of PC-Lint, I don't actually use it for MISRA checking, as the compiler I use has it built in. It would be interesting to know what Gimpel thinks of this. Did you happen to mention this to them?

  5. Michael says:

    No, I hope someone else will take up the challenge. I agree with your assessment of MISRA C. Understanding the reasoning behind the MISRA rules is a great way to learn about some of the pitfalls of C. It is worth noting that a significant number of rules address behavior that it undefined, unspecified or implementation dependent. The first two categories are broadly covered by rule 1.2, but many cases are explicitly addressed by other rules. When it comes to MISRA compliance checking, the main issues are interpretation of the rules and validation of the checker. For these reasons, I think that anyone who is serious about MISRA C should take care in selecting the tool used for checking compliance. For example, PC-Lint 8.00v flags violation of rule 10.1 whenever an unsigned integer is compared with a zero constant. The reason is “Prohibited Implicit Conversion: Signed versus Unsigned”. This may result from a literal interpretation of the rule but it doesn’t make sense. I doubt most programmers would want to add a U suffix to a constant zero so perhaps rule 10.1 could end up being disabled in order to avoid the noise. On the other hand, rule 10.6, which is not currently supported by PC-lint, mandates that a “U” suffix be applied to all constants of unsigned type. IMO this rule falls into the category of “treats you like a child” but there is an important message that underlies the rule. The difference is that PC-Lint [w/o MISRA] will attempt to warn of specific instances that will or may cause a problem whilst MISRA C mandates a very general rule even though only a few instances may cause a problem. Les Hatton [http://www.leshatton.org/index_SA.html] has a lot to say about safer C subsets and has talked about the risk of introducing new defects when trying to “fix” software for “noisy” rules.

  6. ghee says:

    I could not make PC-lint calculate offsetof() at analysis time. But I did not see MISRA's reason for banning offsetof() either.

  7. Rasmus says:

    The posting is a bit dated, but it’s a big (if common) misunderstanding that MISRA compliance means “no warnings”. The MISRA document describes what to do if there are valid technical reasons why violating the MISRA standard is good. In short, you need to have a defined process, a review and a review report. So in case of necessity, you can use anything you want, provided that you can justify and document it. It’s just that inadvertent use of risky C features is banned.

    The reality we’re facing in the industry is that we have a lot of engineers with deep system knowledge, but mediocre programming skills. Trying to outsource this to good coders brings new problems because you can’t specify every detail without practically coding the whole program in natural language, plus that it takes a lot of time that is lost in regard of “time to market”.

    These people are well aware e.g. that switching on engine X under a condition from another system Y needs a special treatment because system Y controls system Z which disables half of the cooling power. That’s is their brilliancy, but they are not aware that e.g. the == operator takes precedence over the & operator. That’s why MISRA states “do not rely on the precedence of C operators”.

  8. […] EmbeddedGurus – Discussion of whether it is worth demonstrating full compliance to MISRA standard […]

  9. Hesham says:

    Thank you so much for taking the time to write this informative article.

  10. Robert Hunt says:

    PCLint wastes much more time than any value you can get out of it. Developing changes from coding in C or C++ to developing in Lint… When prototyping code, you will undoubtedly comment out some code and then Lint gripes about unused variables. And when your build process is very long this becomes painful. PCLint has yet to show me an error in my coding that was serious enough to justify breaking the build.

    • john says:

      Yeah, i had a college blindly follow PCLint and break all verification for our system tests because he optimize a memset that zero’d out system status memory to null terminating.. ouch

Leave a Reply