Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Rule 2.1 : Checking for all possible error status - Is a deviation reasonable for this?
I have the following piece of code for which I get a MISRA Rule 2.1 error. I am considering a deviation for this - All possible error status from a function call can be checked even if the function does not return all possible error statuses. Can you please provide feedback on if this is a reasonable deviation?

(Btw, this is my first post - please feel free to let me know if this is outside the scope here)


#include "stdafx.h"
typedef enum ErrStatus {
    Success = 0,
} ErrStatus;

ErrStatus f(int x) {
    if (x < 0) {
        return Err_1;
        return Success;

    int main()
        ErrStatus x = f(5);
        switch (x)
        case Err_1:
            printf("err 1"); break;
        case Err_2:
            printf("err 2 "); break;  /* Is this dead code ? */
            printf("Success"); break;
The example correctly produces a rule 2.1 violation as it can be determined that "x" will never have the value of "Err_2". A deeper analysis tool might also give a violation on "Err_1" since the value returned by f(5) will always have the value of "Success".

The proposed deviation is not sufficent as stated as there is nothing to prevent a compiler from "optimising" away the code for "Err_1" and "Err_2" cases. Instead the switch chooser should be accessed by means of a volatile qualified lvalue. For example
switch ( *( volatile ErrStatus * ) &x )
This makes the code compliant with this rule AND prevents the case branches being optimised away by the compiler.

When writing a deviation you should read the MISRA Compliance document which can be found at
With respect to this question you should consider the advice given in the MISRA C:2004 14.1 B.1 permit of the "MISRA C 2004 Permits" document, which can be found at This document was written for MISRA-C:2004, but advice given in this permit is relevant to MISRA C:2012.
Posted by and on behalf of the MISRA C Working Group

Forum Jump:

Users browsing this thread: 1 Guest(s)