Code review MISRA 2004 rules

M1.1

Rule 1.1

All code shall conform to ISO 9899:1990.

ANSI C error: <error>

Required

M1.1w

ANSI C warning: <warning>

M 1.2

Rule1.2

Required

M 1.3

M 1.4

Rule1.4

The compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers.

M 1.5

Rule1.5

Floating-point implementations should comply with a defined floating-point standard.

Required

Language extensions

M2.1

Rule 2.1

Required

M2.2

Rule 2.2

Source code shall only use /* ... */ style comments.

M2.3

Rule 2.3

The character sequence /* shall not be used within a comment.

The character sequence /* shall not be used within a comment.

Required

M2.4

Rule 2.4

Sections of code should not be “commented out”

Advisory

Unsupported

Documentation

M3.1

Rule 3.1

Required

Unsupported

M3.2

Rule 3.2

The character set and the corresponding encoding shall be documented.

Required

Unsupported

M3.3

Rule 3.3

Advisory

M3.4

Rule 3.4

All uses of the #pragma directive shall be documented and explained.

Required

M3.5

If it is being relied upon, the implementation-defined behaviour and packing of bitfields shall be documented.

Required

Unsupported

M3.6

All libraries used in production code shall be written to comply with the provisions of this document, and shall have been subject to appropriate.

Required

Unsupported

M4.1.1

Rule 4.1

Required

M4.1.2

M4.2

Rule 4.2

Trigraphs shall not be used.

Trigraph <name> should not be used.

Required

M5.1

Rule 5.1

Identifiers (internal and external) shall not rely on the significance of more than 31 characters.

Identifiers <name> and <name> are identical in the first <value> characters. The number of characters can be specified.

Required

M5.2

Rule 5.2

Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier.

Identifier <name> in an inner scope hides the same identifier in an outer scope : %location%.

M5.3.1

Rule 5.3

The typedef name <name> should not be reused except for its tag. Name already found in %location%.

Required

M5.3.2

M5.4

A tag name shall be a unique identifier.

Required

M5.5

No object or function identifier with static storage duration should be reused.

The static object or function <name> should not be reused. Static object or function already found in %location%.

Advisory

M5.6

Rule 5.6

No identifier in one name space should have the same spelling as an identifier in another name space, with the exception of structure and union member names.

Avoid using the same identifier <name> in two different name spaces. Identifier already found in %location%.

Advisory

M5.7

Rule 5.7

No identifier name should be reused.

The identifier <name> should not be reused. Identifier already found in %location%.

Advisory

M6.1.1

Rule 6.1

The C language plain char type should only be used for character values.

The C language plain char type should only be used for character values.

M6.1.2

Rule 6.1

Case char value is applicable only if the switch statement value is plain character variable.

Required

M6.1.3

Rule 6.1

Avoid using comparison operators on plain char.

Required

M6.2

Rule 6.2

The C language signed char or unsigned char types should only be used for numeric values.

The C language signed char or unsigned char types should only be used for numeric values.

Required

M6.3

Rule 6.3

typedefs that indicate size and signedness should be used in place of the basic types.

The C language numeric type <name> should not be used directly but instead used to define typedef.

Advisory

M6.4.1

Rule 6.4

Bit fields should only be of type 'unsigned int' or 'signed int'.

Required

M6.4.2

Bit fields should not be of type 'enum'.

M6.4.3

Bit fields should only be of explicitly signed or unsigned type.

M6.4.4

Bit fields should not be of type 'boolean' outside c99.

M6.4.5

M6.5

Rule 6.5

Bit fields of type signed int must be at least 2 bits long.

Bit fields of type 'signed int' must be at least 2 bits long.

Required

Constants

M7.1

Rule 7.1

Required

Declarations and definitions

M8.1.1

Rule 8.1

Functions shall have prototype declarations and the prototype shall be visible at both the function definition and call.

Required

M8.1.2

M8.1.3

M8.2.1

Rule 8.2

Whenever an object or function is declared or defined, its type shall be explicitly stated.

The type of <name> should be explicitly stated.

M8.2.2

M8.3

M8.4

M8.5.1

Required

M8.5.2

M8.6

M8.7

M8.8.2

Rule 8.8

Required

M8.8.3

M8.8.4

M8.8.5

M8.9.1

Rule 8.9

M8.9.2

M8.10.1

M8.10.2

M8.11

Rule 8.11

The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage.

Global objects or functions that are only used within the same file should be declared with using the static storage-class specifier.

M8.12

Rule 8.12

When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialisation.

When a global array variable can be used from multiple files, its size should be defined at initialization time.

Required

Initialisation

M9.1

Rule 9.1

Required

M9.2

Rule 9.2

M9.3

Rule 9.3

In an enumerator list, the “=" construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized.

Either all members or only the first member of an enumerator list should be initialized.

Required

Arithmetic type conversions

M10.1.1

Rule 10.1

M10.1.2

Rule 10.1

M10.2

Rule 10.2

Conversion of a complex floating expression is not allowed. Only constant expressions can be implicitly converted and only to a wider floating type of the same signedness.

Required

M10.3

Rule 10.3

The value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlying type of the expression.

Type cast of complex integer expressions is only allowed into a narrower type of the same signedness. Type cast of complex floating expressions is only allowed into a narrower type of the same signedness.

Required

M10.4

Rule 10.4

The value of a complex expression of floating type may only be cast to a narrower floating type.

Required

M10.5

Rule 10.5

If the bitwise operators ~ and << are apply to an operand of underlying type unsigned char or unsigned int, the result shall be immediately cast to the underlying type of the operand.

When using operator '~' or '<<' on 'unsigned char' or 'unsigned int', you should always cast returned value.

Required

M10.6

Rule 10.6

A “U" suffix shall be applied to all constants of unsigned type.

Definitions of unsigned type constants should use the 'U' suffix.

Required

Pointer type conversions

M11.1

Rule 11.1

Conversions shall not be performed between a pointer to a function and any type other than an integral type.

A function pointer should not be converted to another type of pointer.

Required

M11.2

Rule 11.2

Conversions shall not be performed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void.

An object pointer should not be converted to another type of pointer.

Required

M11.3

Rule 11.3

A cast should not be performed between a pointer type and an integral type.

Casting a pointer type to an integer type should not occur.

Advisory

M11.4.1

Rule 11.4

A cast should not be performed between a pointer to object type and a different pointer to object type.

Casting an object pointer type to a different object pointer type should not occur.

Advisory

M11.4.2

M11.5

Rule 11.5

A cast shall not be performed that removes any const or volatile qualification from the type addressed by a pointer.

Casting of pointers to a type that removes any const or volatile qualification on the pointed object should not occur.

Required

Expressions

M12.1

Rule 12.1

Limited dependence should be placed on C’s operator precedence rules in expressions.

Implicit operator precedence may cause ambiguity. Use parenthesis to clarify this expression.

Advisory

M12.2

Rule 12.2

The value of an expression shall be the same under any order of evaluation that the standard permits.

Required

Unsupported

M12.3

Rule 12.3

The sizeof operator should not be used on expressions that contain side effects.

The size of operator should not be used on expressions that contain side effects.

Rule 12.4

The right-hand operand of a logical && or || operator shall not contain side effects.

An expression that contains a side effect should not be used in the right-hand operand of a logical && or || operator.

Required

M12.4.2

The function in the right-hand operand of a logical && or || operator might cause side effects.

M12.5

Rule 12.5

The operands of a logical && or || shall be primary-expressions

Parenthesis should be used around expressions that are operands of a logical && or ||.

M12.6

Rule 12.6

The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !)

Only Boolean operands should be used with logical operators ( &&, || and !).

Advisory

M12.7

Rule 12.7

Bitwise operators shall not be applied to operands whose underlying type is signed.

Bitwise operators should only use unsigned operands.

Required

M12.8

Rule 12.8

The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand.

The right-hand operand of a shift operator should not be too big or negative.

Required

M12.9

Rule 12.9

The unary minus operator shall not be applied to an expression whose underlying type is unsigned.

Only use unary minus operators with signed expressions.

Required

M12.10

Rule 12.10

The comma operator shall not be used.

Do not use the comma operator.

Required

M12.11

Rule 12.11

Evaluation of constant unsigned integer expressions should not lead to wrap around.

M12.12

Rule12.12

The underlying bit representations of floating-point values shall not be used.

Required

Unsupported

M12.13

Rule 12.13

The increment (++) and decrement (–) operators should not be mixed with other operators in an expression.

The increment (++) or the decrement (--) operators should not be used with other operators in an expression.

Advisory

Control statement expressions

M13.1.1

Rule 13.1

Assignment operators shall not be used in expressions that yield a Boolean value .

Required

M13.1.2

Boolean expressions should not contain side effect operators.

M 13.2

Rule 13.2

Tests of a value against zero should be made explicit, unless the operand is effectively Boolean.

Non-Boolean values that are tested against zero should have an explicit test.

M13.3

Rule 13.3

Floating-point expressions shall not be tested for equality or inequality.

The equal or not equal operator should not be used in floating-point expressions.

Required

M13.4

Rule 13.4

The controlling expression of a for statement shall not contain any objects of floating type.

Required

M13.5.1

Rule 13.5

The three expressions of a for statement shall be concerned with loop control only.

Required

M13.5.2

M13.5.3

M13.6

Rule 13.6

Numeric variables being used within a for loop for iteration counting shall not be modified in the body of the loop.

Loop counter of a 'for statement' should not be modified within the body of the loop.

Required

M13.7

Rule 13.7

Boolean operations whose results are invariant shall not be permitted.

Invariant Boolean expressions should not be used.

Required

Control flow

M14.1

Rule 14.1

There shall be no unreachable code.

Unreachable code

Required

M14.2

Rule 14.2

All non-null statements should either: a) have at least one side-effect however executed, or b) cause control flow to change.

Required

M14.3

Rule 14.3

Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment provided that the first character following the null statement is a white-space character.

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.

Required

M14.4

Rule 14.4

The goto statement shall not be used.

Do not use the goto statement.

Required

M14.5

Rule 14.5

The continue statement shall not be used.

Do not use the continue statement.

Required

M14.6

Rule 14.6

For any iteration statement there shall be at most one break statement used for loop termination.

Only one break statement should be used within a loop.

Required

M14.7.1

A function shall have a single point of exit at the end of the function.

Only one exit point should be defined in a function.

Required

M14.7.2

The return keyword should not be used in a conditional block.

M14.8.1

Rule 14.8

The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement.

The switch statement should be followed by a compound statement {}.

Required

M14.8.2

The while statement should be followed by a compound statement {}.

M14.8.3

The do..while statement should contain a compound statement {}.

M14.8.4

The for statement should be followed by a compound statement {}.

M14.9.1

Rule 14.9

An if (expression) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement.

The if (expression) construct should be followed by a compound statement {}.

Required

M14.9.2

The else keyword should be followed by either a compound statement or another if statement.

M14.9.3

The else keyword should be followed by a compound statement.

M14.10

Rule 14.10

All if ... else if constructs shall be terminated with an else clause.

All if ... else if sequences should have an else block.

Required

Switch statements

M15.0

Rule 15.0

Required

M15.1

Rule 15.1

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

M15.2

Rule 15.2

An unconditional break statement shall terminate every non-empty switch clause.

The break statement should only be used to terminate every non-empty switch block.

Required

M15.3.1

Rule 15.3

The final clause of a switch statement shall be the default clause.

The switch statement should have a default clause.

Required

M15.3.2

M15.4.1

Rule 15.4

A switch expression shall not represent a value that is effectively Boolean.

A Boolean should not be used as a switch expression.

Required

M15.4.2

A constant should not be used as a switch expression.

M15.5

Rule 15.5

Every switch statement shall have at least one case clause.

At least one case should be defined in the switch.

Required

Functions

M16.1

Rule 16.1

Functions shall not be defined with a variable number of arguments.

The function <name> should not have a variable number of arguments.

Required

M16.1.2

The library functions 'va_list, va_arg, va_start, va_end, va_copy' should not be used.

Functions shall not call themselves, either directly or indirectly Functions shall not call themselves, either directly or indirectly.

Recursive functions are not allowed. The function <name> is directly recursive.

Required

M16.2.2

Recursive functions are not allowed. The function <name> is recursive when calling <name>.

M16.3

Rule 16.3

Identifiers shall be given for all of the parameters in a function prototype declaration.

The function prototype should name all its parameters.

Required

M16.4

Rule 16.4

The identifiers used in the declaration and definition of a function shall be identical.

The identifiers used in the prototype and definition should be the same.

Required

M16.5

Rule 16.5

Functions with no parameters shall be declared with parameter type void.

Functions with no parameters should use the void type.

Required

M16.6

Rule 16.6

The number of arguments used in the call does not match the number declared in the prototype.

The number of arguments passed to a function shall match the number of parameters.

Required

M16.7

Rule 16.7

A pointer parameter in a function prototype should be declared as pointer to const if the pointer is not used to modify the addressed object.

Use the const qualification for parameter <name> which is pointer and which is not used to change the pointed object.

Required

M16.8

Rule 16.8

All exit paths from a function with non-void return type shall have an explicit return statement with an expression.

The return should always be defined with an expression for non-void functions.

Required

M16.9

Rule 16.9

A function identifier shall only be used with either a preceding &, or with a parenthesized parameter list, which may be empty.

Function identifiers should always use a parenthesis or a preceding &.

Required

M16.10

Rule 16.10

If a function returns error information, then that error information shall be tested.

When a function returns a value, this value should be used.

Required

Pointers and arrays

M17.1

Rule17.1

Required

Unsupported

M17.2

Rule17.2

Pointer subtraction shall only be applied to pointers that address elements of the same array.

Required

M17.3

Rule17.3

Required

M17.4

Rule 17.4

Array indexing shall be the only allowed form of pointer arithmetic.

Required

M17.5

Rule 17.5

A declaration should not use more than two levels of pointer indirection.

The declaration of objects should contain no more than 2 levels of pointer indirection.

Advisory

M17.6

Rule 17.6

The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist.

Required

Structures and unions

M18.1

Rule 18.1

Structure or union types %name% should be finalized before the end of the compilation units.

Structure or union types should be finalized before the end of the compilation units.

Required

M18.2

Rule 18.2

An object shall not be assigned to an overlapping object.

Required

Unsupported

M18.3

Rule 18.3

An area of memory shall not be reused for unrelated purposes.

M18.4

Rule 18.4

Unions shall not be used

Do not use unions.

Required

M19.1

Rule 19.1

#include statements in a file should only be preceded by other preprocessor directives or comments.

Only preprocessor directives or comments may occur before the #include statements.

Advisory

M19.2

Rule 19.2

Do not use non-standard characters in included file names.

Non-standard characters should not occur in header file names in #include directives.

Advisory

M19.3

Rule 19.3

Filenames with the #include directive should always use the <filename> or "filename" syntax.

The #include directive shall be followed by either a <filename> or"filename" sequence.

Required

M19.4

Rule 19.4

A C macro should only be expanded to a constant, a braced initializer, a parenthesised expression, a storage class keyword, a type qualifier, or a do-while-zero block.

C macros shall only expand to a braced initialiser, a constant, a parenthesised expression, a type qualifier, a storage class specifier, or a do-while-zero construct.

Rule 19.5

Macros shall not be #define’d or#undef’d within a block.

Required

M19.6

Rule 19.6

Do not use the #undef directive.

#undefshall not be used.

Required

M19.7

Rule 19.7

Function should be used instead of macros when possible.

A function should be used in preference to a function-like macro.

Advisory

M19.8

Rule 19.8

A function-like macro shall not be invoked without all of its arguments.

Missing argument when calling the macro.

Required

M19.9

Rule 19.9

The preprocessing directive %name% should not be used as argument to the macro.

Arguments to a function-like macro shall not contain tokens that look like preprocessing directives.

Required

M19.10

Rule 19.10

The parameter %name% in the macro should be enclosed in parentheses except when it is used as the operand of # or ##.

In the definition of a function-like macro each instance of a parameter shall be enclosed in parentheses unless it is used as the operand of # or ##.

Required

M19.11

Rule 19.11

Undefined macro identifier in the preprocessor directive.

Required

M19.12

Rule 19.12

The # or ## preprocessor operator should not be used more than once.

There shall be at most one occurrence of the # or # preprocessor operators in a single macro definition.

Required

M19.13

Rule 19.13

The #and #preprocessor operators should not be used.

Advisory

M19.14

Rule 19.14

Only use the 'defined' preprocessor operator with a single identifier.

The defined preprocessor operator shall only be used in one of the two standard forms.

Required

M19.15

Rule 19.15

Header file contents should be protected against multiple inclusions.

Precautions shall be taken in order to prevent the contents of a header file being included twice.

Required

M19.16

Rule 19.16

Possible bad syntax in preprocessing directive.

Required

M19.17

Rule 19.17

A #if, #ifdef, #else, #elif or #endif preprocessor directive has been found without its matching directive in the same file.

All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related.

Required

Standard libraries

M20.1

Rule 20.1

%name% should not be defined, redefined or undefined.

Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined.

Required

M20.2.1

Rule 20.2

#define and #undef shall not be used on a reserved identifier or reserved macro name: Identifier %name% already found in %name%

Required

M20.2.2

#define and #undef shall not be used on identifier beginning with an underscore or on 'defined' keyword: %name%

M20.2.3

Declared identifier should not be a reserved identifier or reserved macro name: Identifier %name% already found in %name%

M20.2.4

Declared identifier should not begin with an underscore or be 'defined' keyword: %name%

M20.2

The names of standard library macros, objects and functions shall not be reused.

Unsupported

M20.3

Rule 20.3

Unsupported

M20.4

Rule 20.4

Dynamic heap memory allocation shall not be used.

This precludes the use of the functions calloc, malloc, realloc free and strdup. There is a whole range of unspecified, undefined and implementation-defined behaviour associated with dynamic memory allocation, as well as a number of other potential pitfalls. Dynamic heap memory allocation may lead to memory leaks, data inconsistency, memory exhaustion, non-deterministic.

Note that some implementations may use dynamic heap memory allocation to implement other functions (for example functions in the library string.h). If this is the case then these functions shall also be avoided.

Required

M20.5

Rule 20.5

errno is a facility of C, which in theory should be useful, but which in practice is poorly defined by the standard. A non zero value may or may not indicate that a problem has occurred; as a result it shall not be used. Even for those functions for which the behaviour of errno is well defined, it is preferable to check the values of inputs before calling the function rather than rely on using errno to trap errors (seeRule 16.10).

Required

M20.6

Rule 20.6

The macro '%name%' should not be used.

Use of this macro can lead to undefined behaviour when the types of the operands are incompatible or when bit fields are used.

Required

M20.7

Rule 20.7

The library macro or function '%name%' should not be used.

The setjmp macro and the longjmp function shall not be used.

Required

M20.8

Rule 20.8

Signal handling contains implementation-defined and undefined behavior.

Required

M20.9

Rule 20.9

The input/output library <%name%> shall not be used in production code.

The input/output library <stdio.h>shall not be used in production code.

Required

M20.10

Rule 20.10

The library macro or function '%name%' should not be used.

The library functions atof, atoi and atol from library <stdlib.h> shall not be used.

Required

M20.11

Rule 20.11

The library functions abort, exit, getenv and system from library <stdlib.h> shall not be used.

Required

M20.12

Rule 20.12

The time handling functions of library <time.h> shall not be used.

M21.1

Rule 21.1

Minimisation of run-time failures shall be ensured by the use of at least one of:

(a) static analysis tools/techniques;

(b) dynamic analysis tools/techniques;

(c) explicit coding of checks to handle run-time faults.

Required

Unsupported