Code review MISRA 2012 rules

The code review tool covers rules from the lists the rules that produced and error or a warning. Each rule can be individually disabled or assigned a Warning or Error severity by using the Rule configuration window. Some rules also have parameters that can be changed. Among other guidelines, the code review tool implements most rules from the MISRA-C:2012 standard, "Guidelines for the use of the C language in critical systems". These rules are referenced with an M prefix. In addition to the industry standard rules, Test Embedded provides some additional coding guidelines, which are referenced with an E prefix.

Code Review - MISRA 2012 rules

Misra rules can be categorized as either Decidable or Undecidable:

A Decidable rule can be checked by a static analyzer, and so, is totally covered within the capabilities of the tool.
An Undecidable rule cannot, in theory, be checked by a static analyzer. If an undecidable rule is covered within the capabilities of the tool, then this rule is partially covered.

Table 1. MISRA rules
Code review reference	MISRA-C: 2012 reference	Decidable/Undecidable	Description	Message	Level	Note
A standard C environment
M1.1	Rule 1.1	Decidable	The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation’s translation limits.	ANSI C error: %name%	Required
M1.1W	Rule 1.1	Decidable		ANSI C warning: %name%	Required
M1.2	Rule 1.2	Undecidable	Language extensions should not be used.	Use of #pragma %name% should always be encapsulated and documented.	Advisory	Partially supported
M1.3	Rule 1.3	Undecidable	There shall be no occurrence of undefined or critical unspecified behaviour.	For more information, see Annex to MISRA 2012 Rule 1.3.	Required	Partially supported
Unused code
M2.1	Rule 2.1	Undecidable	A project shall not contain unreachable code.	Unreachable code.	Required	Partially supported
M2.2.1	Rule 2.2	Undecidable	There shall be no dead code.	A non-null statement should either have a side effect or change the control flow.	Required	Partially supported
M2.2.2				The function %name% is never referenced.
M2.2.3				The object %name% is never referenced
M2.3	Rule 2.3	Decidable	A project should not contain unused type declarations.	Type %name% is never used.	Advisory
M2.4	Rule 2.4	Decidable	A project should not contain unused tag declarations.	Tag %name% is never used.	Advisory
M2.5	Rule 2.5	Decidable	A project should not contain unused macro declarations.	Macro %name% is never used.	Advisory
M2.6	Rule 2.6	Decidable	A function should not contain unused label declarations.	A function should not contain unused label declarations.	Advisory
M2.7	Rule 2.7	Decidable	There should be no unused parameters in functions.	There should be no unused parameters in functions.	Advisory
Comments
M3.1.1	Rule 3.1	Decidable	The character sequences /* and // shall not be used within a comment.	The character sequence /* should not be used within a comment.	Required
M3.1.2	Rule 3.1	Decidable		The character sequence // should not be used within a 'C-style' comment.	Required
M3.2	Rule 3.2	Decidable	Line-splicing shall not be used in // comments.	Line-splicing shall not be used in // comments.	Required
Character sets and lexical conventions
M4.1	Rule 4.1	Decidable	Octal and hexadecimal escape sequences shall be terminated.	Octal and hexadecimal escape sequences shall be term inated.	Required
M4.2	Rule 4.2	Decidable	Trigraphs should not be used.	Trigraphs should not be used.	Advisory
Identifiers
M5.1.1	Rule 5.1	Decidable	External identifiers shall be distinct in the first 31 characters.	External identifiers %name% and %name% are identical in the first %param% characters.	Required
M5.1.2	Rule 5.1	Decidable	External identifiers shall be distinct in the first 6 characters ignoring case.		Required
M5.2	Rule 5.2	Decidable	Identifiers declared in the same scope and name space shall be distinct.	Identifiers %name% declared in the same scope and name space shall be distinct. Identifier identical in the first %param% characters already found in %location%.	Required
M5.3	Rule 5.3	Decidable	An identifier declared in an inner scope shall not hide an identifier declared in an outer scope.	Identifier %name% declared in an inner scope shall not hide an identifier declared in an outer scope. Identifier identical in the first %param% characters already found in %location%	Required
M5.4.1	Rule 5.4	Decidable	Macro identifiers shall be distinct.	Macros %name% and %name% are identical in the first %param% characters	Required
M5.4.2	Rule 5.4	Decidable	Macro identifiers shall be distinct.	Macros %name% and %name% are identical in the first %param% characters ignoring case.	Required
M5.5.1	Rule 5.5	Decidable	Identifiers shall be distinct from macro names.	Macro %name% and identifier %name% are identical in the first %param% characters.	Required
M5.5.2	Rule 5.5	Decidable	Identifiers shall be distinct from macro names.	Macro %name% and identifier %name% are identical in the first %param% characters ignoring case.	Required
M5.6	Rule 5.6	Decidable	A typedef name shall be a unique identifier.	The typedef name %name% should not be reused except for its tag. Name already found in %location%	Required
M5.7.1	Rule 5.7	Decidable	The tag name %name% should not be reused.	The tag name %name% should not be reused. Name already found %location%	Required
M5.7.2	Rule 5.7	Decidable	The tag name %name% should not be reused.	A struct and union cannot use the same tag name.	Required
M5.8	Rule 5.8	Decidable	Identifiers that define objects or functions with external linkage shall be unique.	Identifiers '%name%' that defines objects or functions with external linkage shall be unique. Identifier already found in %location%	Required
M5.9	Rule 5.9	Decidable	Identifiers that define objects or functions with internal linkage should be unique.	Identifiers or macro '%name%' and '%name%'are ambiguous because of possible character confusion.	Advisory
Types
M6.1.1	Rule 6.1	Decidable	Bit- fields shall only be declared with an appropriate type.	Bit fields should only be of type 'unsigned int' or 'signed int'.	Required
M6.1.2				Bit fields should not be of type 'enum'.
M6.1.3				Bit fields should only be of explicitly signed or unsigned type.
M6.1.4				Bit fields should not be of type 'boolean' under c99.
M6.1.5				Bit fields should not be of type 'boolean' under c99.
M6.2	Rule 6.2	Decidable	Single-bit fields shall not be of a signed type.	Bit fields of type 'signed int' must be at least 2 bits long.	Required
Literals and constants
M7.1	Rule 7.1	Decidable	Octal constants shall not be used.	Octal constants shall not be used.	Required
M7.2	Rule 7.2	Decidable	A "u" or "U" suffix shall be applied to all integer constants that are represented in an unsigned type.	Definitions of unassigned type constants should use the "U" suffix.	Required
M7.3	Rule 7.3	Decidable	The lowercase character l" shall not be used in a literal suffix.	The lowercase character “l” shall not be used in a literal suffix.	Required
M7.4	Rule 7.4	Decidable	A string literal shall not be assigned to an object unless the object's type is pointer to a const-qualified char.	A string literal shall not be assigned to an object unless the object’s type is “pointer to const-qualified char”.	Required
Declarations and definitions
M8.1	Rule 8.1	Decidable	Types shall be explicitly specified.	The type of '%name%' should be explicitly stated.	Required
M8.2.1	Rule 8.2	Decidable	Function types shall be in prototype form with named parameters.	The function prototype should name all its parameters.	Required
M8.2.2				Functions with no parameters should use the void type.
M8.2.3				The type of parameter %name% should be explicitly stated.
M8.3.1	Rule 8.3	Decidable	All declarations of an object or function shall use the same names and type qualifiers.	Parameters and return types should use compatible type in the declaration and in the definition.	Required
M8.3.2	Rule 8.3	Decidable		The identifiers used in the prototype and definition should be the same.	Required
M8.4.1	Rule 8.4	Decidable	A compatible declaration shall be visible when an object or function with external linkage is defined.	A prototype for the global function %name% should be declared before defining the function.	Required
M8.4.2				A prototype for the global object %name% should be declared before defining the object.
M8.4.3				If objects or functions are declared multiple times their types should be compatible.
M8.5	Rule 8.5	Decidable	An external object or function shall be declared once in one and only one file.	Identifiers %name% that declare objects or functions with external linkage shall be declared once in one and only one file.	Required
M8.6	Rule 8.6	Decidable	An identifier with external linkage shall have exactly one external definition.	Identifiers %name% that declare objects or functions with external linkage shall be unique.	Required
M8.7.1	Rule 8.7	Decidable	Functions and objects should not be defined with external linkage if they are referenced in only one translation unit.	Global object %name% that are only used within the same file should be declared using the static storage-class specifier.	Advisory
M8.7.2	Rule 8.7	Decidable		Global function %name% that are only used within the same file should be declared using the static storage-class specifier.	Advisory
M8.8	Rule 8.8	Decidable	The static storage class specifier shall be used in all declarations of objects and functions that have internal linkage.	Global objects or functions %name% that are only used within the same file should be declared with using the static storage-class specifier.	Required
M8.9	Rule 8.9	Decidable	An object should be defined at block scope if its identifier only appears in a single function.	Global objects should not be declared if they are only used from within a single function.	Advisory
M8.10	Rule 8.10	Decidable	An inline function shall be declared with the static storage class.	Inline function %name% should be static.	Required
M8.11	Rule 8.11	Decidable	When an array with external linkage is declared, its size should be explicitly specified.	When a global array variable can be used for multiple files, its size should be defined at initialization time.	Advisory
M8.12	Rule 8.12	Decidable	Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique.	Enumeration member '%name%' have a not unique implicitly-specified value.	Required
M8.13	Rule 8.13	Undecidable	A pointer should point to a const-qualified type whenever possible.		Advisory	Unsupported
M8.14	Rule 8.14	Decidable	The restrict type qualifier shall not be used.	The restrict type qualifier shall not be used.	Required
Initialization
M9.1	Rule 9.1	Undecidable	The value of an object with automatic storage duration shall not be read before it has been set		Mandatory	Unsupported
M9.2	Rule 9.2	Decidable	The initializer for an aggregate or union shall be enclosed in braces.	Nested braces should be used to initialize nested multi-dimension arrays and nested structures.	Required Note: Exception not covered
M9.3	Rule 9.3	Decidable	Arrays shall not be partially initialized.	Arrays shall not be partially initialized.	Required Note: Exception not covered
M9.4	Rule 9.4	Decidable	An element of an object shall not be in itialized more than once.	An element of an object shall not be initialized more than once.	Required
M9.5	Rule 9.5	Decidable	Where designated initializers are used to initialize an array object the size of the array shall be specified explicitly.	Where designated initializers are used t o initialize an array object the size of the array shall be specified explicitly.	Required
The essential type model
M10.1.2	Rule 10.1	Decidable	Operands shall not be of an inappropriate essential type.	Operand should be boolean.	Required
M10.1.3				Can't use a boolean as a numeric value.
M10.1.4				Can't use a char as a numeric value.
M10.1.5				Can't use a not anonymous enum as a numeric value.
M10.1.6				Shift and bitwise operations should be performed on unsigned value.
M10.1.7				Right hand operand of shift operation should be performed on unsigned value.
M10.1.8				Unary minus operation should not be performed on unsigned value.
M10.2	Rule10.2	Decidable	Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations.	Expressions of essentially character type shall not be used inappropriately in addition and subtraction operations.	Required
M10.3.1	Rule10.3	Decidable	The value of an expression shall not be assigned to an object with a narrower essential type or of a different essential type category.	The value of an expression shall not be assigned to an object with a narrower essential type.	Required
M10.3.2	Rule10.3	Decidable		The value of an expression shall not be assigned to an object with a different essential type category.	Required
M10.4	Rule 10.4	Decidable	Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category.	Both operands of a n operator in which the usual arithmetic conversions are performed s hall have the same essential type category.	Required
M10.5	Rule 10.5	Decidable	The value of an expression should not be cast to an inappropriate essential type.	The value of an expression should not be cast to an inappropriate essential type.	Advisory
M10.6	Rule 10.6	Decidable	The value of a composite expression shall not be assigned to an object with wider essential type.	The value of an expression should not be cast to an inappropriate essential type.	Required
M10.7	Rule 10.7	Decidable	If a composite expression is used as one operand of an operation in which the usual arithmetic conversions are performed then the other operand shall not have wider essential type.	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.	Required
M10.8	Rule 10.8	Decidable	The value of a composite expression shall not be cast to a different essential type category or a wider essential type.	The value of a composite expression shall not be cast to a different essential type category or a wider essential type.	Required
Pointer type conversions
M11.1	Rule 11.1	Decidable	Conversions shall not be performed between a pointer to a function and any other type.	A function pointer should not be converted to another type of pointer.	Required
M11.2	Rule 11.2	Decidable	Conversions shall not be performed between a pointer to an incomplete type and any other type.	Conversions shall not be performed between a pointer to an incomplete type and any other type.	Required
M11.3.1	Rule 11.3	Decidable	A cast shall not be performed between a pointer to object type and a pointer to a different object type.	Casting an object pointer type to a different object pointer type should not occur.	Required
M11.3.2				Casting an object pointer type to a different object pointer type should not occur, especially when object sizes are not the same.
M11.3.3				An object pointer should not be converted to another type of pointer.
M11.4	Rule 11.4	Decidable	A conversion should not be performed between a pointer to object and an integer type.	A conversion should not be performed between a pointer to object and an integer type.	Advisory
M11.5	Rule 11.5	Decidable	A conversion should not be performed from pointer to void into pointer to object.	A conversion should not be performed from pointer to void into pointer to object.	Advisory
M11.6	Rule 11.6	Decidable	A cast shall not be performed between pointer to void and and an arithmetic type.	A cast shall not be performed between pointer to void and an arithmetic type.	Required
M11.7	Rule 11.7	Decidable	A cast shall not be performed between pointer to object and a non-integer arithmetic type.	A cast shall not be performed between pointer to object and a non-integer arithmetic type.	Required
M11.8	Rule 11.8	Decidable	A cast shall not remove any const or volatile qualification from the type pointed to by a pointer.	Casting of pointers to a type that removes any const or volatile qualification on the pointed object should not occur.	Required
M11.9	Rule 11.9	Decidable	The macro NULL shall be the only permitted form of integer null pointer constant.		Required
Expressions
M12.1.2	Rule 12.1	Decidable	The precedence of operators within expressions should be made explicit.	Implicit bitwise operator precedence may cause ambiguity. Use parenthesis to clarify this expression.	Advisory
M12.1.3				Parenthesis should be used around expressions that are operands of a logical &amp;&amp; or \|\|
M12.1.4				Parenthesis should be used around expression that is operand of 'sizeof' operator.
M12.2	Rule 12.2	Undecidable	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		Required	Unsupported
M12.3	Rule 12.3	Decidable	The comma operator should not be used.	The comma operator should not be used.	Advisory
M12.4	Rule 12.4	Decidable	Implicit bitwise operator precedence may cause ambiguity. Use parenthesis to clarify this expression.	Evaluation of constant expressions should not lead to unsigned integer wrap-around.	Advisory
Side effects
M13.1	Rule 13.1	Undecidable	Initializer lists shall not contain persistent side effects.		Required	Unsupported
M13.2	Rule 13.2	Undecidable	The value of an expression and its persistent side effects shall be the same under all permitted evaluation orders.		Required	Unsupported
M13.3	Rule 13.3	Decidable	a full expression containing an increment (++) or decrement (--) operator should have no other potential side effects other than that caused by the increment or decrement operator.	The increment '++' or decrement '–' operators should not be used with other operators in an expression.	Advisory
M13.4.1	Rule 13.4	Decidable	The result of an assignment operator should not be used.	Boolean expressions should not contain assignment operators.	Advisory
M13.4.2	Rule 13.4	Decidable	The result of an assignment operator should not be used.	The result of an assignment operator should not be used in an expression.	Advisory
M13.5	Rule 13.5	Undecidable	The right hand operand of a logical && or \|\| operator shall not contain persistent side effects		Required	Unsupported
M13.6	Rule 13.6	Decidable	The operand of the sizeof operator shall not contain any expression which has potential side effects.	The sizeof operator should not be used on expressions that contain side effects.	Mandatory
Control statement expressions
M14.1.1	Rule 14.1	Undecidable	A loop counter shall not have essentially floating type.	Floating-point variables should not be used to control a for statement.	Required	Partially supported
M14.2.1	Rule 14.2	Undecidable	A for loop shall be well-formed.	Only loop counter should be initialized in a for loop initialization part.	Required	Partially supported
M14.2.2				In the 'update part' of a 'for statement', only 'loop counter' should be updated.
M14.2.3				There should be one and only one loop counter for loop statement.
M14.2.4				Loop counter of a 'for statement' should not be modified within the body of the loop.
M14.3.1	Rule 14.3	Undecidable	Controlling expressions shall not be invariant.	Invariant Boolean expressions should not be used.	Required	Partially supported
M14.4	Rule 14.4	Decidable	The controlling expression of an if statement and the controlling expression of an iteration- statement shall have essentially Boolean type.	Non-Boolean values that are tested against zero should have an explicit test.	Required
Control flow
M15.1	Rule 15.1	Decidable	The goto statement should not be used.	Do not use the goto statement.	Advisory
M15.2	Rule 15.2	Decidable	The goto statement shall jump to a label declared later in the same function.	The goto statement shall jump to a label declared later in the same function.	Required
M15.3	Rule 15.3	Decidable	Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.	Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.	Required
M15.4	Rule 15.4	Decidable	There should be no more than one break or goto statement used to terminate any iteration statement.	There should be no more than one break or goto statement used to terminate any iteration statement.	Advisory
M15.5	Rule 15.5	Decidable	A function should have a single point of exit at the end.	Only one exit point should be defined in a function.	Advisory
M15.6.1	Rule 15.6	Decidable	The body of an iteration-statement or a selection-statement shall be a compound-statement.	The switch statement should be followed by a compound statement.	Required
M15.6.2				The while statement should be followed by a compound statement.
M15.6.3				The do..while statement should contain a compound statement.
M15.6.4				The for statement should be followed by a compound statement.
M15.6.5				The if (expression) construct should be followed by a compound statement.
M15.6.6				The else keyword should be followed by either a compound statement or another 'if' statement.
M15.7	Rule 15.7	Decidable	All if ... else constructs shall be terminated with an else statement.	All if ... else if constructs shall be terminated with an else statement.	Required
Switch statements
M16.1	Rule 16.1	Decidable	All switch statement should be well formed.	A switch block should start with a case.	Required
M16.2	Rule 16.2	Decidable	A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement.	A case or default statements should only be used directly within the compound block of a switch statement.	Required
M16.3	Rule 16.3	Decidable	An unconditional break statement shall terminate every switch-clauses.	The break statement should be used to terminate every non-empty switch-block.	Required
M16.4	Rule 16.4	Decidable	Every switch statement shall have a default label.	Every switch statement shall have a default label.	Required
M16.5	Rule 16.5	Decidable	A default label appear as either the first or the last switch label of a switch statement.	The default clause should be the first or the last clause of a switch statement.	Required
M16.6	Rule 16.6	Decidable	Every switch statement shall have at least two switch-clauses.	Every switch statement shall have at least two switch-clauses.	Required
M16.7	Rule 16.7	Decidable	A switch expression shall not have essentially Boolean type.	A Boolean should not be used as a switch expression.	Required
Switch statements
M17.1.1	Rule 17.1	Decidable	The features of <stdarg.h> shall not be used.	The function '%name%' should not have a variable number of arguments.	Required
M17.1.1	Rule 17.1	Decidable	The va_list, va_arg, va_start, va_end and va_copy functions of <stdarg.h> shall not be used.	The library function %name% should not be used.	Required
M17.2.1	Rule 17.2	Undecidable	Functions shall not call themselves, either directly or indirectly.	Recursive functions are not allowed. The function '%name%' is directly recursive.	Required	Partially supported
M17.2.2	Rule 17.2	Undecidable		Recursive functions are not allowed. The function '%name%' is recursive when calling '%name%'.	Required	Partially supported
M17.3	Rule 17.3	Decidable	A function shall not be declared implicitly.	A prototype for the function '%name%' should be declared before calling the function.	Mandatory
M17.4	Rule 17.4	Decidable	All exit paths from a function with non-void return type shall have an explicit return statement with an expression.	All exit paths from a function with non-void return type shall have an explicit return statement with an expression.	Mandatory
M17.5	Rule 17.5	Undecidable	The function argument corresponding to a parameter declared to have an array type shall have an appropriate number of elements.		Advisory	Unsupported
M17.6	Rule 17.6	Decidable	The declaration of an array parameter shall not contain the static keyword between the [].	The declaration of an array parameter shall not contain the static keyword between the [].	Mandatory
M17.7	Rule 17.7	Decidable	The value returned by function having non-void return type shall be used.	When a function returns a value, this value should be used.	Required
M17.8	Rule 17.8	Undecidable	A function parameter should not be modified.		Advisory	Unsupported
Pointers and arrays
M18.1	Rule 18.1	Undecidable	A pointer resulting from arithmetic on a pointer operand shall address an element of the same array as that pointer operand.		Required	Unsupported
M18.2	Rule 18.2	Undecidable	Subtraction between pointers shall only be applied to pointers that address elements of the same array.		Required	Unsupported
M18.3	Rule 18.3	Undecidable	The relational operators >, >=, < and <= shall not be applied to objects of pointer type except where they point into the same object.		Required	Unsupported
M18.4	Rule 18.4	Decidable	The +, -, += and -= operators should not be applied to an expression of pointer type.	Pointer arthimetic except array indexing, should not be used.	Advisory
M18.5	Rule 18.5	Decidable	Declarations should contain no more than two levels of pointer nesting.	A declaration should not use more than two levels of pointer indirection.	Advisory
M18.6	Rule 18.6	Undecidable	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.		Required	Unsupported
M18.7	Rule 18.7	Decidable	Flexible arrays members shall not be declared.	Flexible array members shall not be declared.	Required
M18.8	Rule 18.8	Decidable	Variable-length array types shall not be used.	Variable-length array types shall not be used.	Required
Overlapping storage
M19.1	Rule 19.1	Undecidable	An object shall not be assigned or copied to an overlapping object / unsupported.		Mandatory	Unsupported
M19.2	Rule 19.2	Decidable	The union keyword should not be used.	Do not use unions.	Advisory
Preprocessing directives
M20.1	Rule 20.1	Decidable	#include directive should only be preceded by preprocessor directives or comments.	Only preprocessor directives or comments may occur before the #include statements.	Advisory
M20.2	Rule 20.2	Decidable	The ', or \ character and the /* or // character sequences shall not occur in a header file name"	Do not use non-standard characters in included files names.	Required
M20.3	Rule 20.3	Decidable	The #include directive shall be followed by either a <filename> or a filename" sequence"	Filenames with the #include directive should always use the <filename> or "filename" syntax.	Required
M20.4	Rule 20.4	Decidable	A macro shall not be defined with the same name as a keyword.	A macro shall not be defined with the same name as a keyword %name%	Required
M20.5	Rule 20.5	Decidable	#undef should not be used.	Do not use the #undef directive.	Advisory
M20.6	Rule 20.6	Decidable	Token that look like a preprocessing directive should not occur withing a macro argument.	The preprocessing directive %name% should not be used as argument macro argument.	Required
M20.7	Rule 20.7	Decidable	Expressions resulting from the expansion of macro parameters shall be enclosed in parenthesis.	The parameter %name% in the macro should be enclosed in parentheses except when it is used as the operand of # or ##.	Required
M20.8	Rule 20.8	Decidable	The controlling expression of a #if or #elif preprocessing directive shall evaluate to 0 or 1.	The controlling expression of a #i f or #elif preprocessing directive shall evaluate to 0 or 1	Required
M20.9	Rule 20.9	Decidable	All identifiers used in the controlling expression of #if or #elif preprocessing directives shall be #define'd before evaluation.	Undefined macro identifier in the preprcessor directive.	Required
M20.10	Rule 20.10	Decidable	The # and ## preprocessor operators should not be used.	The # and ## preprocessor operators should be avoided.	Advisory
M20.11	Rule 20.11	Decidable	A macro parameter immediately following a # operator shall not immediately be followed by a ## operator.	A macro parameter immediately fol lowing a # operator shall not immediately be followed by a ## operator.	Required
M20.12	Rule 20.12	Decidable	A macro parameter used as an operand to the # and ## operators shall only be used as an operand to these operators.	Macro parameter %name% used as an operandto the # and ## operators shall not be used elsewhere in this macro.	Required
M20.13	Rule 20.13	Decidable	A line whose first token is # shall be a valid preprocessing directive.	Possible bad syntax in preprocessing directive.	Required
M20.14	Rule 20.14	Decidable	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.	All #else, #elif and #endif preprocessor directives shall reside in the same file a s the #if, #ifdef or #ifndef directive to which they are related.	Required
Standard libraries
M21.1.1	Rule 21.1	Decidable	#define and #undef shall not be used on a reserved identifier or reserved macro name: Identifier %name% already found in <%name%>.	#define and #undef shall not be used on a reserved identifier or reserved macro name.	Required
M21.1.2	Rule 21.1	Decidable		#define and #undef shall not be used on identifier beginning with an underscore or on 'defined' keyword %name%	Required
M21.2.1	Rule 21.2	Decidable	A reserved identifier or macro name shall not be declared.	Declared identifier should not be a reserved identifier or reserved macro name: Identifier %name% already found in <%name%>.	Required
M21.2.2	Rule 21.2	Decidable	A reserved identifier or macro name shall not be declared.	Declared identifier should not begin with an underscore or be 'defined' keyword %name%	Required
M21.3	Rule 21.3	Decidable	The memory allocation and deallocation functions of shall not be used.	Dynamic heap memory allocation:'%name%' shall not be used.	Required
M21.4	Rule 21.4	Decidable	The standard header file <setjmp.h> shall not be used.	The standard header file <%name%> shall not be used.	Required
M21.5	Rule 21.5	Decidable	The standard header file <signal.h> shall not be used.	The signal handling facilities of <%name%>shall not be used.	Required
M21.6.1	Rule 21.6	Decidable	The input/output library <stdio.h> shall not be used in production code.	The input/output library <%name%> shall not be used in production code.	Required
M21.6.2	Rule 21.6	Decidable	The input/output library <wchar.h> shall not be used in production code.	The input/output library <%name%> shall not be used in production code.	Required
M21.7	Rule 21.7	Decidable	The atof, atoi, atol and atoll functions of shall not be used.	The library macro or %name% shall not be used.	Required
M21.8	Rule 21.8	Decidable	The library functions abort, exit, getenv and system of shall not be used.	The library macro or function %name% should not be used.	Required
M21.9	Rule 21.9	Decidable	The library macro or functions bsearch and qsort of <stdlib.h> shall not be used.	The library macro or function %name% shall not be used.	Required
M21.10	Rule 21.10	Decidable	The Standard Library time and date functions shall not be used.	The time handling functions of library %name% shall not be used.	Required
M21.11	Rule 21.11	Decidable	The standard header file <tgmath.h> shall not be used.	The standard header file %name% shall not be used.	Required
M21.12	Rule 21.12	Decidable	The exception handling features of should not be used.	The library macro or function %name% should not be used.	Advisory
Resources
M22.1	Rule 22.1	Undecidable	All resources obtained dynamically by means of Standard Library functions shall be explicitly released.		Required	Unsupported
M22.2	Rule 22.2	Undecidable	A block of memory shall only be freed if it was allocated by means of a Standard Library function.		Mandatory	Unsupported
M22.3	Rule 22.3	Undecidable	The same file shall not be open for read and write access at the same time on different streams.		Required	Unsupported
M22.4	Rule 22.4	Undecidable	There shall be no attempt to write to a stream which has been opened as read-only.		Mandatory	Unsupported
M22.5	Rule 22.5	Undecidable	A pointer to a FILE object shall not be referenced.		Mandatory	Unsupported
M22.6	Rule 22.6	Undecidable	The value of a pointer to a FILE shall not be used after the associated stream has been closed.		Mandatory	Unsupported

In addition to the MISRA rules, Test Embedded includes extended rules that you can select or not select to complete your static analysis.

Table 2. Extended rules
Code review reference	Message
E1.1	Functions should have less than '%param%' lines (current value: %name%).
E.1.2	Functions should have less than '%param%' V(g) complexity (current value: %name%).
E1.3	Functions should have less than '%param%' lines, outside empty lines (current value: %name%).
E1.4	Functions should have less than '%param%' lines, outside empty lines or comment lines (current value: %name%).
E1.5	Functions should have less than '%param%' lines, outside empty lines, comment lines or bracket lines (current value: %name%).Lines are not counted in the following cases:
E1.6	Compilation units should define less than '%param%' functions (current value: %name%).
E1.7	Compilation units should define less than '%param%' variables (current value: %name%).
E1.8	Compilation units should have less than '%param%' lines (current value: %name%).
E1.9	Compilation unit should have less than '%param%' lines, not counting empty lines (current value: %name%).
E1.10	Compilation unit should have less than '%param%' lines not counting empty lines or comments (current value: %name%).
E1.11	Compilation unit should have less than '%param%' lines not counting empty lines, comments or brackets (current value: %name%).
E1.12	Functions should have less than '%param%' parameters (current value: %name%).
E3.1	A null statement in original source code should be on a separate line and the semicolon should be followed by at least one white space and then a comment
E4.1	Only ISO C escape sequences are allowed
E.4.2	Only ISO C escape sequences are allowed(\v)
E5.1	Identifiers or macro '%name%' and '%name%' are ambiguous because of possible character confusion.
E5.2	Possible typing mistake between the macro or identifier '%name%' and '%name%' because of repeating character.
E5.3	The identifier '%name%' should not be reused. Identifier already found in %location%.
E5.4	Identifier %name% in an inner scope hides the same identifier in an outer scope: %location%.
E5.5	The typedef name %name% should not be reused even for its tag. Name already found in %location%.
E6.1	The C language numeric type %name% should not be used directly but instead used to define typedef.
E6.2	The implicit 'int' type should not be used.
E.8.1	Parameters and return types should use exactly the same type names in the declaration and in the definition.
E.8.2	A prototype for the static function %name% should be declared before defining the function..
E.8.3	Static function %name% should only be declared in a single file. Redundant declaration found at: %name%.
E.8.4	Static object %name% should only be declared in a single file. Redundant declaration found at: %location%.
E.8.5	Either all members or only the first member of an enumerator list should be initialized.
E.8.6	The body of function %name% should not be located in a header file.
E.8.7	The memory storage (definition) for the variable %name% should not be in a header file.
E.8.8	Functions should not be declared at block scope
E.8.10	The global object or function %name% %name% should have exactly one external definition. No definition found.
E.8.11	Use the const qualification for variable %name% which is pointer and which is not used to change the pointed object.
E9.1	Variables with automatic storage duration should be initialized before being used.
E9.2	The global variable %name% is not initialized.
E10.1	When using operator '~' or '&lt;&lt;' on 'unsigned char' or 'unsigned int', you should always cast returned value.
E12.1	The operator on a Boolean expression should be a logical operator ( &&, \|\| or !).
E12.2	Ternary expression '?:' should not be used.
E12.3	Expressions should not cause a side effect assignment.
E12.4	The equal or not equal operator should not be used in floating-point expressions.
E13.1	Boolean expressions should not contain side effect operators.
E13.2	An expression that contains a side effect should not be used in the right-hand operand of a logical && or \|\| operator.
E13.3	The function in the right-hand operand of a logical && or \|\| operator might cause side effects
E15.1	Do not use the continue statement
E15.2	Only one break statement should be used within a loop
E15.3	The return keyword should not be used in a conditional block
E15.4	The else keyword should be followed by a compound statement.
E16.1	Case char value is applicable only if the switch statement value is plain character variable.
E16.2	A constant should not be used as a switch expression.
E16.3	The switch expression should not have side effects.
E17.1	The number of arguments used in the call does not match the number declared in the prototype.
E17.2	Use the const qualification for parameter '%name%' which is pointer and which is not used to change the pointed object.
E17.3	Function identifiers should always use a parenthesis or a preceding &
E19.1	Structure or union types '%name%' should be finalized before the end of the compilation units.
E20.1	Header file contents should be protected against multiple inclusions.
E20.2	The # or ## preprocessor operator should not be used more than once.
E20.3	Missing argument when calling the macro.
E20.4	Only use the 'defined' preprocessor operator with a single identifier.
E20.5	Macro definitions or '#undef' should not be located within a block.
E20.6	A C macro should only be expanded to a constant, a braced initialiser, a parenthesised expression, a storage class keyword, a type qualifier, or a do-while-zero block.
E21.1	The variable 'errno' should not be used.
E21.2	The macro 'offsetof' should not be used.
E21.3	The library macro or function 'setjmp,longjmp,sigsetjmp,siglongjmp' should not be used.