Comments on: Is MISRA compliance worthwhile?

By: ghee

ghee — Sat, 09 Jan 2010 01:50:26 +0000

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

By: Michael

Michael — Thu, 15 Oct 2009 12:42:00 +0000

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.

By: Nigel Jones

Nigel Jones — Wed, 14 Oct 2009 11:00:31 +0000

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?

By: Michael

Michael — Wed, 14 Oct 2009 08:07:59 +0000

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.

By: Nigel Jones

Nigel Jones — Mon, 12 Oct 2009 16:47:44 +0000

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.

By: Tom Harris

Tom Harris — Mon, 12 Oct 2009 15:32:00 +0000

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?