Am I allowed to choose to disable these two MISRA rules: one statement per function and mandatory function prototypes?

Question

Our company are now ISO-13485 (Medical devices) and wants to use MISRAC2012. I read the standard, but I cannot figure out whether or not I am allowed to disable some rules if I think it could improve both stability and readability.

Two examples:

MISRA only allows 1 return statement per function. This often lead to nested conditional structures that look like Christmas tree. I really don't think this rule increase safeness because it makes the code less readable and more error prone.

MISRA only accept functions that have a prototype, even for static ones. This allows the programmer to place his functions anywhere in the file without respect of the calling order. Without prototype the main function has to be the latest function in the file and multi-function recursion is not possible because a function can only call the one declared above itself.

If I want to disable these two rules, can I do it? Would any customer blame me for this?

Answer 1

MISRA-C:2012 has 3 categories that all directives and rules sort under:

• Mandatory. You must follow these and you are not allowed to make deviations.
• Required. You must follow these, but you are allowed to break them if you raise a formal deviation from the rule. You need a good reason why.
• Advisory. It is recommended to follow these, but you can break them without raising a formal deviation (although raising a deviation is recommended practice).

The idea behind deviations is that your company should have a routine to deal with them, such as an internal quality errand or something to bring up during code review meetings etc. The idea is that someone else except yourself must be involved in the process of creating a deviation, preferably someone with extensive C knowledge. This is described in MISRA-C 5.4 and there's also an additional guidance document called MISRA Compliance:2016 that might be helpful.

My personal advise for how to implement deviations, is to not allow them at all on case-by-case basis. Instead, a separate coding standard document for the company should be established - you need some manner of document to claim MISRA compliance anyway. This document should contain a list of all company-wide deviations. If there is a need to deviate, the company-wide document must be updated. This actually saves you from implementing a lot of bureaucracy routines and it saves you from various less experienced programmers coming up with weird ideas, just because they don't understand the MISRA-C rationale for the rule.

---

As for the one return statement per function, it is in my opinion a known defect in MISRA-C inherited from IEC 61508 (I think I'm the only one who actually bothered researching where the requirement comes from). You should raise a permanent deviation against the rule, since it is nonsense. Personally I rephrased the requirement as "functions should not have more than one return statement, unless several return statements leads to more readable code". This covers what was hopefully the true intention of the rule, namely to avoid spaghetti programming.

---

MISRA only accept functions that have a prototype, even for static ones. This allows the programmer to place his functions anywhere in the file without respect of the calling order. Without prototype the main function has to be the latest function in the file and multi-function recursion is not possible because a function can only call the one declared above itself.

I don't believe this makes any sense, seems like you are trying to solve a problem which doesn't exist. You should avoid accidental recursion by 1) actually knowing what you are doing and 2) use static analysis tools, as required by MISRA.

If you want the call stack to be func1() -> func2() -> func3() and block func2() or func3() from calling func1(), that is best solved with proper program design. Giving the functions intuitive names and using common sense will get you very far.

If that's not enough, then you can split your translation unit in two and create a separate h/c file pair for the internals. The risk you describe is mostly a problem if you have very long source files with a lot of functions in them, to the point where the programmer is losing track of them. That too is a good indication that the file (and/or the functions) should be split in several.

As for the rationale behind this MISRA rule, it is a very sound one, namely to block old C90 crap from "inventing" a calling convention (implicit int return type, making up parameters etc), just because the compiler can't find a function prototype. You definitely should not deviate from this rule.