Rule 1.1 | MISRA-C2012-1.1 | The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation’s translation limits. |
Rule 1.2 | MISRA-C2012-1.2 | Language extensions should not be used |
Rule 1.3 | MISRA-C2012-1.3 | There shall be no occurrence of undefined or critical unspecified behaviour |
Rule 2.1 | MISRA-C2012-2.1 | A project shall not contain unreachable code |
Rule 2.2 | MISRA-C2012-2.2 | There shall be no dead code |
Rule 2.3 | MISRA-C2012-2.3 | A project should not contain unused type declarations |
Rule 2.4 | MISRA-C2012-2.4 | A project should not contain unused tag declarations |
Rule 2.5 | MISRA-C2012-2.5 | A project should not contain unused macro declarations |
Rule 2.6 | MISRA-C2012-2.6 | A function should not contain unused label declarations |
Rule 2.7 | MISRA-C2012-2.7 | There should be no unused parameters in functions |
Rule 3.1 | MISRA-C2012-3.1 | The character sequences /* an // shall not be used within a comment |
Rule 3.2 | MISRA-C2012-3.2 | If the source line containing a // comment ends with a \ character in the source character set, the next line becomes part of the comment. This may result in unintentional removal of code. |
Rule 4.1 | MISRA-C2012-4.1 | Octal and hexadecimal escape sequences shall be terminated |
Rule 4.2 | MISRA-C2012-4.2 | Trigraphs should not be used |
Rule 5.1 | MISRA-C2012-5.1 | External identifiers shall be distinct |
Rule 5.2 | MISRA-C2012-5.2 | Identifiers declared in the same scope and name space shall be distinct |
Rule 5.3 | MISRA-C2012-5.3 | An identifier declared in an inner scope shall not hide an identifier declared in an outer scope |
Rule 5.4 | MISRA-C2012-5.4 | Macro identifiers shall be distinct |
Rule 5.5 | MISRA-C2012-5.5 | Identifiers shall be distinct from macro names |
Rule 5.6 | MISRA-C2012-5.6 | A typedef name shall be a unique identifier |
Rule 5.7 | MISRA-C2012-5.7 | A tag name shall be a unique identifier |
Rule 5.8 | MISRA-C2012-5.8 | Identifiers that define objects or functions with external linkage shall be unique |
Rule 5.9 | MISRA-C2012-5.9 | Identifiers that define objects or functions with internal linkage should be unique |
Rule 6.1 | MISRA_C2012-6.1 | Bit-fields shall only be declared with an appropriate type |
Rule 6.2 | MISRA-C2012-6.2 | Single-bit named bit fields shall not be of a signed type |
Rule 7.1 | MISRA-C2012-7.1 | Octal constants shall not be used |
Rule 7.2 | MISRA_C2012-7.2 | A “u” or “U” suffix shall be applied to all integer constants that are represented in an unsigned type |
Rule 7.3 | MISRA-C2012-7.3 | The lowercase character “l” shall not be used in a literal suffix |
Rule 7.4 | MISRA-C2012-7.4 | A string literal shall not be assigned to an object unless the object's type is pointer to const-qualified char |
Rule 8.1 | MISRA-C2012-8.1 | Types shall be explicitly specified |
Rule 8.2 | MISRA-C2012-8.2 | Function types shall be in prototype form with named parameters |
Rule 8.3 | MISRA-C2012-8.3 | All declarations of an object or function shall use the same names and type qualifiers |
Rule 8.4 | MISRA-C2012-8.4 | A compatible declaration shall be visible when an object or function with external linkage is defined |
Rule 8.5 | MISRA-C2012-8.5 | An external object or function shall be declared once in one and only one file |
Rule 8.6 MISRA-C2012-8.6 | MISRA-C2012-8.6 | An identifier with external linkage shall have exactly one external definition |
Rule 8.7 | MISRA-C2012-8.7 | Functions and objects should not be defined with external linkage if they are referenced in only one translation unit |
Rule 8.8 | MISRA-C2012-8.8 | The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage |
Rule 8.9 | MISRA-C2012-8.9 | An object should be defined at block scope if its identifier only appears in a single function |
Rule 8.10 | MISRA-C2012-8.10 | An inline function shall be declared with the static storage class |
Rule 8.11 | MISRA-C2012-8.11 | When an array with external linkage is declared, its size should be explicitly specified |
Rule 8.12 | MISRA-C2012-8.12 | Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique |
Rule 8.13 | MISRA-C2012-8.13 | A pointer should point to a const-qualified type whenever possible |
Rule 8.14 | MiSRA-C2012-8.14 | The restrict type qualifi er shall not be used |
Rule 9.1 | MISRA-C2012-9.1 | The value of an object with automatic storage duration shall not be read before it has been set |
Rule 9.2 | MISRA-C2012-9.2 | The initializer for an aggregate or union shall be enclosed in braces |
Rule 9.3 | MISRA-C2012-9.3 | Arrays shall not be partially initialized |
Rule 9.4 | MISRA-C2012-9.4 | An element of an object shall not be in itialized more than once |
Rule 9.5 | MISRA-C2012-9.5 | Where designated initializers are used t o initialize an array object the size of the array shall be specified explicitly |
Rule 10 | MISRA-C2012-10.1 | 1Operands shall not be of an inappropriate essential type |
Rule 10.2 | MISRA-C2012-10.2 | Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations |
Rule 10.3 | MISRA-C2012-10.3 | The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category |
Rule 10.4 | MISRA-C2012-10.4 | Both operands of an operator in which the usual arithmetic conversions are performed s hall have the same essential type category |
Rule 10.5 | MISRA_C2012-10.5 | The value of an expression should not be cast to an inappropriate essential type |
Rule 10.6 | MISRA-C2012-10.6 | The value of a composite expression shall not be assigned to an object with wider essential type |
Rule 10.7 | MISRA-C2012-10.7 | If a composite expression is used as one operand of an operator in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type |
Rule 10.8 | MISRA-C2012-10.8 | The value of a composite expression shall not be cast to a different essential type category or a wider essential type |
Rule 11.1 | MISRA-C2012-11.1 | Conversions shall not be performed between a pointer to a function and any other type |
Rule 11.2 | MISRA-C2012-11.2 | Conversions shall not be performed between a pointer to an incomplete type and any other type |
Rule 11.3 | MISRA-C2012-11.3 | A cast shall not be performed between a pointer to object type and a pointer to a different object type |
Rule 11.4 | MISRA-C2012-11.4 | A conversion should not be performed between a pointer to object and an integer type |
Rule 11.5 | MISRA-C2012-11.5 | A conversion should not be performed from pointer to void into pointer to object |
Rule 11.6 | MISRA-C2012-11.6 | A cast shall not be performed between pointer to void and an arithmetic type |
Rule 11.7 | MISRA-C2012-11.7 | A cast shall not be performed between pointer to object and a noninteger arithmetic type |
Rule 11.8 | MISRA-C2012-11.8 | A cast shall not remove any const or volatile qualification from the type pointed to by a pointer |
Rule 11.9 | MISRA-C2012-11.9 | The macro NULL shall be the only per mitted form of integer null pointer constant |
Rule 12.1 | MiSRA-C2012-12.1 | The precedence of operators within expressions should be made explicit |
Rule 12.2 | MISRA-C2012-12.2 | The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand |
Rule 12.3 | MISRA-C2012-12.3 | The comma operator should not be used |
Rule 12.4 | MISRA-C2012-12.4 | Evaluation of constant expressions should not lead to unsigned integer wrap-around |
Rule 13.1 | MISRA-C2012-13.1 | Initializer lists shall not contain persistent side eff ects |
Rule 13.2 | MISRA-C2012-13.2 | The value of an expression and its persistent side eff ects shall be the same under all permitted evaluation orders |
Rule 13.3 | MISRA-C2012-13.3 | A full expression containing an increment (++) or decrement (--) operator should hav e no other potential side eff ects other than that caused by the increment or decrement operator |
Rule 13.4 | MISRA-C2012-13.4 | The result of an assignment operator should not be used |
Rule 13.5 | MISRA-C2012-13.5 | The right hand operand of a logical && or || operator shall not contain persistent side effects |
Rule 13.6 | MISRA-C2012-13.6 | The operand of the size of operator shall not contain any expression which has potential side effects |
Rule 14.1 | MISRA-C2012-14.1 | A loop counter shall not have essentially floating type |
Rule 14.2 | MISRA-C2012-14.2 | A for loop shall be well-formed |
Rule 14.3 | MISRA-C2012-14.3 | Controlling expressions shall not be invariant |
Rule 14.4 | MISRA-C2012-14.4 | The controlling expression of an if statement and the controlling expression of an iteration- statement shall have essentially Boolean type |
Rule 15.1 | MISRA-C2012-15.1 | The goto statement should not be used |
Rule 15.2 | MISRA-C2012-15.2 | The goto statement shall jump to a label declared later in the same function |
Rule 15.3 | MISRA-C2012-15.3 | Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement |
Rule 15.4 | MISRA-C2012-15.4 | There should be no more than one break or goto statement used to terminate any iteration statement |
Rule 15.5 | MISRA-C2012-15.5 | A function should have a single point of exit at the end |
Rule 15.6 | MISRA-C2012-15.6 | The body of an iteration-statement or a selection-statement shall be a compound-statement |
Rule 15.7 | MISRA-C2012-15.7 | All if … else if constructs shall be terminated with an else statement |
Rule 16.1 | MISRA-C2012-16.1 | All switch statements shall be well-formed |
Rule 16.2 | MISRA-C2012-16.2 | A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement |
Rule 16.3 | MISRA-C2012-16.3 | An unconditional break statement shall terminate every switch-clause |
Rule 16.4 | MISRA-C2012-16.4 | Every switch statement shall have a default label |
Rule 16.5 | MISRA-C2012-16.5 | A default label shall appear as either the first or the last switch label of a switch statement |
Rule 16.6 | MISRA-C2012-16.6 | Every switch statement shall have at least two switch-clauses |
Rule 16.7 | MISRA-C2012-16.7 | A switch-expression shall not have essentially Boolean type |
Rule 17.1 | MISRA-C2012-17.1 | The features of shall not be used |
Rule 17.2 | MISRA-C2012-17.2 | Functions shall not call themselves, either directly or indirectly |
Rule 17.3 | MISRA-C2012-17.3 | A function shall not be declared implicitly |
Rule 17.4 | MISRA-C2012-17.4 | All exit paths from a function with non-void return type shall have an explicit return statement with an expression |
Rule 17.5 | MISRA-C2012-17.5 | The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements |
Rule 17.6 | MISRA-C2012-17.6 | The declaration of an array parameter shall not contain the static keyword between the [ ] |
Rule 17.7 | MISRA-C2012-17.7 | The value returned by a function having non-void return type shall be used |
Rule 17.8 | MISRA-C2012-17.8 | A function parameter should not be modified |
Rule 18.1 | MISRA-C2012-18.1 | A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand |
Rule 18.3 | MISRA-C2012-18.3 | The relational operators >, >=, < and <= shall not be applied to objects of pointer type except where they point into the same object |
Rule 18.4 | MISRA-C2012-18.4 | The +, -, += and -= operators should not be applied to an expression of pointer type |
Rule 18.5 | MISRA-C2012-18.5 | Declarations should contain no more than two levels of pointer nesting |
Rule 18.6 | MISRA-C2012-18.6 | The address of an object with automatic storage shall not be copied to another object that persists after the first object has ceased to exist |
Rule 18.7 | MISRA-C2012-18.7 | Flexible array members shall not be declared |
Rule 18.8 | MISRA-C2012-18.8 | Variable-length array types shall not be used |
Rule 19.2 | MiSRA-C2012-19.2 | The union keyword should not be used |
Rule 20.1 | MISRA-C2012-20.1 | |
Rule 20.2 | MISRA-C2012-20.2 | The ', " or \ characters and the /* or // character sequences shall not occur in a header file name |
Rule 20.3 | MISRA-C2012-20.3 | The #include directive shall be followed by either a or "filename" sequence |
Rule 20.4 | MISRA-C2012-20.4 | A macro shall not be defined with the same name as a keyword |
Rule 20.5 | MISRA-C2012-20.5 | |
Rule 20.6 | MISRA-C2012-20.6 | Tokens that look like a preprocessing directive shall not occur within a macro argument |
Rule 20.7 | MISRA-C2012-20.7 | Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses |
Rule 20.8 | MISRA-C2012-20.8 | The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1 |
Rule 20.9 | MISRA-C2012-20.9 | All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #defi ne’d before evaluation |
Rule 20.10 | MISRA-C2012-21.10 | The # and ## preprocessor operators should not be used |
Rule 20.11 | Misra-c2012-21.11 | A macro parameter immediately following a # operator shall not immediately be followed by a ## operator |
Rule 20.12 | MISRA-C2012-21.12 | A macro parameter used as an operand to the # or ## o perators, which is itself subj ect to further macro replacement, shall only be used as an operand to these operators |
Rule 20.13 | MISRA-C2012-20.13 | A line whose first token is # shall be a valid preprocessing directive |
Rule 20.14 | MISRA-C2012-20.14 | All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if, #ifdef or #ifndef directive to which they are related |
Rule 21.1 | MISRA-C2012-21.1 | |
Rule 21.2 | MISRA-C2012-21.2 | A reserved identifier or macro name shall not be declared |
Rule 21.3 | MISRA-C2012-21.3 | The memory allocation and deallocation functions of shall not be used |
Rule 21.4 | MISRA-C2012-21.4 | The standard header file shall not be used |
Rule 21.5 | MISRA-C2012-21.5 | The standard header file shall not be used |
Rule 21.6 | MISRA-C2012-21.6 | The Standard Library input/output functions shall not be used |
Rule 21.7 | MISRA-C2012-21.7 | The atof, atoi, atol and atoll functions of shall not be used |
Rule 21.8 | MISRA-C2012-21.8 | The library functions abort, exit, getenv and system of shall not be used |
Rule 21.9 | MISRA-C2012-21.9 | The library functions bsearch and qsort of shall not be used |
Rule 21.10 | MISRA-C2012-21.10 | The Standard Library time and date functions shall not be used |
Rule 21.11 | MISRA-C2012-21.11 | The standard header file shall not be used |
Rule 21.12 | MISRA-C2012-21.12 | The exception handling features of should not be used |
Rule 22.1 | MISRA-C2012-22.1 | All resources obtained dynamically by means of Standard Library functions shall be explicitly released |
Rule 22.2 | MISRA-C2012-22.2 | A block of memory shall only be freed if it was allocated by means of a Standard Library function |
Rule 22.4 | MISRA-C2012-22.4 | There shall be no attempt to write to a stream which has been opened as read-only |
Rule 22.5 | MISRA-C2012-22.5 | A pointer to a FILE object shall not be dereferenced |
Rule 22.6 | MISRA-C2012-22.6 | The value of a pointer to a FILE shall not be used after the associated stream has been closed |
