Rules in previous versions of MISRA C were divided into two categories: Required Rules and Advisory Rules. If code was to be MISRA C compliant it had to comply with every Required Rule unless a formal deviation could be raised. Deviations had to have a comprehensively documented reason for the non-compliance. Advisory Rules were by definition more flexible and did not require a formal deviation.
MISRA C:2012 has added a NEW third category – Mandatory Rules. These are non-negotiable rules whereby deviations are simply not permitted – because it is difficult to envisage a situation whereby non-compliance could ever be justified.
Rule compliance and enforceability
As the use of coding standards in general and MISRA C in particular has become widespread, the problem of how to define “compliance” has been brought into sharp focus. There is an acute need for coding rules, wherever possible:
a) To be clearly and unambiguously defined
b) To be statically enforceable
c) To be decidable
These are some of the guiding principles that have driven the development of MISRA C and they are the principles that have encouraged the development of widespread tool support for enforcement of the rules.
The capability of static analysis tools to provide reliable and accurate rule enforcement varies widely and in the absence of independent tool certification, claims of compliance with MISRA C need to be carefully scrutinized.
Therefore, care needs to be taken in any tool selection because a characteristic of prime importance for any coding rule is the extent to which it can be enforced using static analysis tools. Automatic rule enforcement is a highly significant issue for several reasons:
a) It saves a lot of time
b) It is immediate, reliable, repeatable and consistent
c) It reduces dependence on manual code reviews and the attendant potential for embarrassment and argument
Image: Old vs. New: MISRA C:2012 incorporates a more differentiated approach towards software engineering