MISRA rules that don’t make sense

on May 13, 10 • by Alen Zukich • with 7 Comments

Previously I posted the value of using coding standards, specifically MISRA C and MISRA C++.  This time I wanted to go through some general experiences we had with some of the checkers, specifically the ones that seem to throw a lot of violated rules, to the point that on some code bases MISRA flagged more ...

Home » Software Compliance » MISRA rules that don’t make sense

Previously I posted the value of using coding standards, specifically MISRA C and MISRA C++.  This time I wanted to go through some general experiences we had with some of the checkers, specifically the ones that seem to throw a lot of violated rules, to the point that on some code bases MISRA flagged more than one error per LOC!

There are still tons of great rules you can apply even if you don’t make an embedded product.  But as I said before, it doesn’t make sense to turn on all the MISRA rules.  After running through many code bases and looking at the value of MISRA we certainly noticed a trend with a few culprits.  Here are a few examples that we found to be noisy with non-MISRA compliant code.

MISRA C 6.3 and MISRA C++ 3-9-2:

MISRA has the distinction of “required” rules and “advisory” rules.  This is an “advisory” rule.  Essentially it wants you to avoid using types like char, int, short, long etc. and to use specific length typedefs instead.  Obviously, many code bases use the basic types, so be prepared for many issues.

MISRA C 14.9 and MISRA C++ 6-4-1:

This is a “required” rule.  This rule  is really about making sure you have braces for your if/else keywords.  Good practice to have but how many of us really do this?

MISRA C 12.13 and MISRA C++ 5-2-10:

This is an “advisory” rule.  The rule doesn’t want you to mix increment and decrement operators into an expression.  This makes sense because it can be pretty confusing to read.  But in our experiments this seems to be something that many developers do.

MISRA C 17.4 and MISRA C++ 5-0-15:

This is a “required” rule.  The rule only wants to allow you to use array indexing for pointer arithmetic.  Everything else is non-compliant.

MISRA C 14.7 and MISRA C++ 6-6-5:

This is a “required” rule and another control flow example.  A function can only have one point of exit at the end of a function.  I can understand this but as you know, that is not reality.

MISRA C 13.2:

This is an “advisory” rule.  It states that tests against zero should be made explicit.  In other words: if (x != 0) is the proper way, not if (x).  The exception to this is if the operand is Boolean.  I don’t know about you, but you can crown me the super wiener on this? I never make it explicit.

So if you plan to pick up MISRA on your existing project beware of these rules.  I’d like to hear if you do any of those things in your code base.

Related Posts

7 Responses to MISRA rules that don’t make sense

  1. DERN says:

    I think this article is quite ridiculous, claiming a rule is not good because we pretend that nobody respect that means the refusal of all kind of improvement. So in these conditions, as many of us drive and have phone calls at the same time it shall be allowed to do it? Of course not, ridiculous rules are rules that protect against no or very little risks. If you want to do such an article, please do it with a risk related discussion. We don’t care all the recurrent mistakes you have seen, the question is: if do those mistakes what are the risks?
    As an example M2012 D1.1 “All source files shall compile without any compilation errors”, is quite ridiculous because compilation error won’t produce a binary so no risk. Better rule is “All source files shall compile without any compilation warnings”… But “A function should be used in preference to a function-like macro where they are interchangeable” is advisory while it should have been required…

    • Walter Capitani says:

      Jerome – you raise a very good point, that the use of any static code analysis rules (and the resulting work it takes to investigate and correct the issues found) should always be relative to the risk. The point of this article is that using MISRA rules on non-MISRA compliant code can generate lots of noise, so you need to consider if enabling these rules is “worth the risk”.

  2. Phil says:

    A couple of points:
    1) MISRA C is not intended to be applied to existing code – you either adopt it at the start of a project (and comply with the rules you select to enforce), or you suffer pain when applying it after-the-fact.
    2) Whilst some of the rules may appear to be fussy, they do allow real defects to be identified. Sure, the hit/miss ratio may be low, but in high-integrity systems all defects need to be found and eliminated.
    Personally, I always use {…} for if..else, while, etc. and make tests explicit. Once you get into the habit (or use a template based editor) it has zero overhead.

    • Walter Capitani says:

      Good points! Thanks for the feedback. We have seen some projects where MISRA is applied after the fact but it certainly makes things more challenging, so it’s good to be aware of the items in this post. In general, it’s up to the project (or customer) to decide which rules make sense to apply, balancing the effort against the required integrity of the software.

  3. vlad says:

    If someone doesn’t use these rules doesn’t mean they have no sense. Reading/maintaining code compliant with MISRA is much easier.

  4. Mark says:

    6-6-5 – the checker we are using flags every function which doesn’t have an explict ‘return’ as the final statement. We’ve written functions for years, only using the ‘return’ statement when there was a value to be returned.

    6-4-2 – All if…else if constructs must be terminated with an else clause. I don’t see how adding unneeded else clauses, containing null statements is helpful. It leads to…

    6-2-3 – a null statement shall be on a line by itself. So you can’t add an endline comment explaining that you’re just trying satisfy 6-4-2.

    6-4-6 – final clause of switch statement shall be default. We often default to a “middle case”, e.g.,
    switch (color)
    {
    case red:
    stop();
    break;
    case yellow:
    default:
    caution();
    break;
    case green:
    go();
    break;
    }

  5. Erik says:

    > I’d like to hear if you do any of those things in your code base.

    I rarely use pointer arithmetic. Maybe in driver code when assigning registers. But that is it. As far as using !x instead of x != 0, I do that exclusively in C++. It just seems more readable to me. I would find 13.2 very annoying.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top