Enabled Services

parser B.PARSER

The code shall be parsable without errors by the ECLAIR parser. If the code is parsed with errors the AST is incomplete and the results of ECLAIR analyses are likely to be incorrect

reporter B.REPORT.ECB

Output reports in ECB format

reporter B.REPORT.ERR

Output B.PARSER error reports in plain text to standard error

rule MC2.1.1 (required)

Reports code that does not conform to the C90 standard

rule MC2.1.2 (required)

Reports code that depends on any undefined or unspecified behavior as given by the C90 standard Annex G

rule MC2.1.3 (required)

If more than one compiler and/or language is used to compile and link the source files, then there must be a common defined interface standard for object code to which these languages/compilers/assemblers conform

rule MC2.1.4 (required)

Reports if the compiler used by the program is not specified as supporting 31 character significance and case sensitivity for external identifiers

rule MC2.1.5 (advisory)

If floating-point types are used, then the floating-point standard used by the implementation must be documented

rule MC2.2.1 (required)

Assembly language instructions must be encapsulated in assembler functions, in C functions that contain no other C code or in macros

rule MC2.2.2 (required)

Reports any comments not using the `/* ... */' style

rule MC2.2.3 (required)

Reports any use of the character sequence `/*' inside a comment

rule MC2.2.4 (advisory)

Reports sections of code that are commented out

rule MC2.3.1 (required)

Any use of code that has implementation-defined behavior defined by Annex G.3 in the C90 standard, that is not specifically addressed by other MISRA rules, must be documented

rule MC2.3.2 (required)

The source and execution character sets and the corresponding encoding must be documented

rule MC2.3.3 (advisory)

If integer division is used, its expected direction of rounding in the chosen compiler must be documented

rule MC2.3.4 (required)

Checks that each `#pragma' directive is documented

rule MC2.3.5 (required)

If there is a reference to a `class', `struct' or `union' that contains a bit-field then the implementation-defined behaviour and packing of bit-fields must be documented

rule MC2.3.6 (required)

Any libraries such as the standard libraries, third-party libraries or libraries designed in-house and used by the project must be written to be MISRA-compliant and subject to appropriate validation

rule MC2.4.1 (required)

Reports any escape sequences that are not defined in the C90 standard

rule MC2.4.2 (required)

Reports any trigraphs

rule MC2.5.1 (required)

Identifiers (including macro names) must differ in their first 31 characters both before and after any macro expansion

rule MC2.5.2 (required)

No identifier may use the same name as (and hence hide) an identifier in an outer scope

rule MC2.5.3 (required)

A typedef name must not be used for any other entity

rule MC2.5.4 (required)

A tag name must not be used for any other entity

rule MC2.5.5 (advisory)

Any identifier of a variable or function with static storage duration must not be reused by any other any other entity anywhere

rule MC2.5.6 (advisory)

Reports if an identifier in one namespace has the same name as another identifier in another namespace unless both of them are for `struct' or `union' members

rule MC2.5.7 (advisory)

No entity may use the same identifier name as any other entity except when all the entities with the same name have the same declaration in a header file and that file is included in multiple source files

rule MC2.6.1 (required)

A variable with plain `char' type must not be used for numeric values

rule MC2.6.2 (required)

Variables with `unsigned' or `signed' `char' type must not be used for non-numeric values

rule MC2.6.3 (advisory)

Reports any direct use of signed and unsigned variants of `char', `int', `short', `long', `long long', `float', `double' or `long double' and any typedef name for any of these variants that does not indicate the size and signedness

rule MC2.6.4 (required)

Bitfields must be explicitly defined as `signed' `int' or `unsigned' `int'

rule MC2.6.5 (required)

Bitfields (even if unnamed) whose type is `signed' must have a length greater than 1 bit

rule MC2.7.1 (required)

There must be no occurrence of an octal constant or an octal escape sequence

rule MC2.8.1 (required)

A function must have a prototype declaration visible to its definition and before any reference to it

rule MC2.8.2 (required)

In the declarations for variables, functions and typedefs the types must be explicitly stated

rule MC2.8.3 (required)

The types of the corresponding parameters or return value in the prototype declarations and/or definition of a function must be identical (types that are identical use the same `typedef' names, the same desugared type and have the same qualifiers)

rule MC2.8.4 (required)

Reports if multiple declarations or definition of the same variable or function have incompatible types

rule MC2.8.5 (required)

Reports any variable or function definition in a header file

rule MC2.8.6 (required)

Reports functions declared at block scope

rule MC2.8.7 (required)

Reports any referenced variable that is global or has file scope and for which all references are in the same function

rule MC2.8.8 (required)

Any variable or function with external linkage must be declared at most once in a header file

rule MC2.8.9 (required)

Reports a variable or function with external linkage that is undefined or has more than one definition

rule MC2.8.10 (required)

All declarations and definitions of variables or functions at file scope must have internal linkage unless external linkage is required

rule MC2.8.11 (required)

Any variable or function declaration or definition with internal linkage must include the storage class specifier `static'

rule MC2.8.12 (required)

Any array declaration with external linkage must be initialized or the size must be explicitly stated

rule MC2.9.1 (required)

All automatic variables must have a value written to them before being read

rule MC2.9.2 (required)

All non-zero initialization of arrays or structures must use braces that match their structure

rule MC2.9.3 (required)

Each enumeration initializer must initialise none, just the first or all the enumeration constants

rule MC2.10.1 (required)

Reports if the value of an expression with integer type is implicitly converted to a different underlying type and one of the following holds: 1. the conversion is not to a wider integer type of the same signedness; 2. the expression is complex; 3. the expression is not constant and is a function argument; 4. the expression is not constant and is a return expression

rule MC2.10.2 (required)

Reports the value of an expression with floating-point type that is implicitly converted to a different type and one of the following holds: 1. the conversion is not to a wider floating-point type; 2. the expression is complex; 3. the expression is a function argument; 4. the expression is a return expression

rule MC2.10.3 (required)

The value of a complex expression of integer type must not be cast to a type that: 1. is wider than the underlying type of the expression, or 2. has a different signedness to that of the underlying type of the expression

rule MC2.10.4 (required)

The value of a complex expression of floating-point type must not be cast to a wider floating-point type

rule MC2.10.5 (required)

If an operand of `<<' or `~' has underlying type `unsigned' `char' or `short', then the result must be immediately cast to the underlying type of the operand

rule MC2.10.6 (required)

Any integer constant whose magnitude is such that it is intrinsically unsigned must have a `U' or `u' suffix

rule MC2.11.1 (required)

A function pointer must only be converted: 1. to or from an integer type; or 2. from a null pointer constant that was explicitly cast to `void*'

rule MC2.11.2 (required)

A pointer to a non-function may only be converted to or from: 1. an integral type, or 2. another pointer to object type, or 3. a pointer to void

rule MC2.11.3 (advisory)

A pointer type must not be cast to an integer type and an integer type must not be cast to a pointer type

rule MC2.11.4 (advisory)

A pointer to non-function, non-void type must not be cast to a pointer to a different non-function, non-void type (the canonical form and ignoring any qualifications)

rule MC2.11.5 (required)

A pointer to a type with a `const' or `volatile' qualifier must not be cast to a pointer to type without the qualifier

rule MC2.12.1 (advisory)

Parentheses must be used in expressions to indicate the expected operator precedence

rule MC2.12.2 (required)

The value of an expression must not depend on the unspecified order of evaluation defined in the C90 standard

rule MC2.12.3 (required)

If a `sizeof' operator is applied to an expression, then that expression must be a (possibly volatile) object

rule MC2.12.4 (required)

Reports if the right-hand operand of a logical `&&' or `||' operator contains side effects

rule MC2.12.5 (required)

An operand of a logical `&&' or `||' operator must be either: 1. a primary expression (i.e., a single identifier, constant or parenthesized expression); or 2. a binary logical expression with the same operator

rule MC2.12.6 (advisory)

Numeric and Boolean expressions should be placed in appropriate contexts

rule MC2.12.6L (advisory)

Numeric and Boolean expressions should be placed in appropriate contexts

rule MC2.12.7 (required)

Reports any the bitwise operators: `~', `<<', `<<=', `>>', `>>=', `&', `&=', `^', `^=', `|' and `|=' that are applied to operands whose underlying type is signed

rule MC2.12.8 (required)

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

rule MC2.12.9 (required)

Reports a unary minus operator that is applied to an expression whose underlying type is unsigned

rule MC2.12.10 (required)

Reports any use of the comma operator

rule MC2.12.11 (advisory)

Any constant unsigned integer expression that leads to wrap-around may only occur within the context of an explicit cast

rule MC2.12.12 (required)

There must be no access to an object of floating-point type via a `union' or via a pointer to a memory area where an object of floating-point type may be stored

rule MC2.12.13 (advisory)

The increment or decrement operator must not be used when there is another side-effect in the same statement or if the result is used within that expression

rule MC2.13.1 (required)

In the object sources, reports an assignment operator that is used as an operand of a logical operator or as the condition part of a selection or iteration statement

rule MC2.13.2 (advisory)

Any expression that does not have an effectively Boolean type must not used in a Boolean context

rule MC2.13.3 (required)

Reports any floating-point expressions that are tested for equality or inequality

rule MC2.13.4 (required)

Any variable, call expression, array subscript expression, member expression, complex expression or dereference expression with floating point type must not be used in the controlling part of a `for' statement

rule MC2.13.5 (required)

Reports `for' statement loops that cannot be proved to have a finite number of iterations

rule MC2.13.5L (required)

Reports `for' statement loops that cannot be proved to have a finite number of iterations

rule MC2.13.6 (required)

A `for' statement loop counter must not be modified in the loop body

rule MC2.13.7 (required)

A Boolean expression must not always have the same value

rule MC2.14.1 (required)

Reports any unreachable code

rule MC2.14.2 (required)

Reports any expression whose value is ignored and has no side-effects

rule MC2.14.3 (required)

Reports a null statement that is not on a line by itself

rule MC2.14.4 (required)

Reports any `goto' statement (indirect or direct)

rule MC2.14.5 (required)

Reports any `continue' statement

rule MC2.14.6 (required)

Reports if there is more than one `break' statement that may terminate a `do', `for', or `while' statement

rule MC2.14.7 (required)

Reports any `return' statement that is not the last statement in a function

rule MC2.14.8 (required)

Reports any `switch', `do', `for', or `while' statement that does not have its body enclosed in braces

rule MC2.14.9 (required)

In an `if' statement: 1. the condition part must be immediately followed by a compound statement; 2. any `else' keyword must be followed by another `if' statement or by a compound statement

rule MC2.14.10 (required)

Any `if' statement with `else if' clauses must have the final `else if' followed by an `else' clause or a comment

rule MC2.15.0 (required)

A switch statement must be as defined in the normative text in Section 6.15, page 71 of MISRA-C:2004 that is not covered by the MISRA Rules 15.1, 15,2, 15.3, 15.4 and 15.5

rule MC2.15.1 (required)

The scope of any `case' or `default' label must be the compound statement that forms the body of a `switch'

rule MC2.15.2 (required)

A `case' or `default' clause must either end with a `break' statement or the clause must be a compound statement whose last statement is a `break' statement

rule MC2.15.3 (required)

Any `switch' statement must end with the `default' clause

rule MC2.15.4 (required)

The value of any `switch' expression must not have essentially Boolean type

rule MC2.15.5 (required)

Reports any `switch' statement that does not have a `case' label

rule MC2.16.1 (required)

Functions must not be defined with ellipsis and there must be no use of standard library functions or macros with a variable number of arguments

rule MC2.16.2 (required)

No function definition may call itself directly or indirectly via a chain of function calls

rule MC2.16.3 (required)

Checks that each parameter declaration in a function prototype declaration has an identifier

rule MC2.16.4 (required)

Parameter declarations that are in matching positions in two declarations or definitions for the same function must have the same identifiers

rule MC2.16.5 (required)

All function declarations must have non-empty parameter lists

rule MC2.16.6 (required)

Any call to a function must have an explicit protoype declaration, and the number of arguments passed to the function must match the number of parameters in the prototype

rule MC2.16.7 (advisory)

Any pointer parameter in a function prototype that is not used to modify the addressed object must be declared as pointer to `const'

rule MC2.16.8 (required)

Any non-void function definition must not have: 1. a return statement with an empty expression; 2. any exit path that does not terminate with a return statement

rule MC2.16.9 (required)

A function identifier must be preceded by `&' or followed by, a possibly empty, parenthesized list of call arguments

rule MC2.16.10 (required)

If a function returns a value that contains some error information, then the value of a call to that function must not be cast to `void' and any error information must be checked

rule MC2.17.1 (required)

If an integer is added to or subtracted from a pointer, then that pointer must point to an array or an array element

rule MC2.17.2 (required)

If one pointer is subtracted from another pointer, then both pointers must point to elements in the same array

rule MC2.17.3 (required)

If any of the operators `>', `>=', `<', `<=' are used to compare the values of pointers then both operands must point to elements in the same array

rule MC2.17.4 (required)

There must be no pointer arithmetic except for array indexing where the indexed object is explicitly declared to have an array type

rule MC2.17.5 (advisory)

Reports if the declared type of an object has more than 2 levels of pointer indirection

rule MC2.17.6 (required)

An object with automatic storage must not have its address: 1. assigned to another automatic object of larger scope; or 2. assigned to a static object; or 3. returned by a function

rule MC2.18.1 (required)

Reports any structure or union declaration with incomplete type that is referenced in a translation unit

rule MC2.18.2 (required)

Reports if an object may be assigned to an overlapping object

rule MC2.18.3 (required)

There must be documentation that states if and how an area of memory may be reused for unrelated data

rule MC2.18.4 (required)

There must be no `union' declaration, no declaration whose type is a `union', or any use of a `union' type

rule MC2.19.1 (advisory)

Reports if an `#include' directive is preceded by any code apart from other preprocessor directives or comments

rule MC2.19.2 (advisory)

The characters `'', `\', `"', or `/*' must not be used between `<' and `>' delimiters and the characters `'', `\' or `/*' must not be used between `"' delimiters in a header name preprocessing token

rule MC2.19.3 (required)

Reports any `#include' directive that is not followed by a filename delimited by `<'`>' or double quotes

rule MC2.19.4 (required)

A macro body must not have unbalanced brackets and may only expand to one of the following: a braced initialiser, a constant, a string literal, a parenthesized expression, a type qualifier, a storage class specifier, or a do-while-zero loop idiom

rule MC2.19.5 (required)

The `#define' or `#undef' directive must never occur inside a block

rule MC2.19.6 (required)

Reports any use of the `#undef' directive

rule MC2.19.7 (advisory)

An invocation of a function-like macro should not be replaceable by a function call

rule MC2.19.8 (required)

Any call to a function-like macro must have the same number of arguments as the number of parameters in the macro's definition and all its arguments must be non-empty

rule MC2.19.9 (required)

No argument to a call to a function-like macro may be a single `#' or contain a `#' followed by a directive name (other than as part of a comment, character literal or string literal)

rule MC2.19.10 (required)

Any occurrence of a macro parameter in the macro's body must be enclosed in parentheses unless it is: 1. an operand for the `#' or `##' operators; 2. (possibly indirectly) the identifier for a field reference

rule MC2.19.11 (required)

No undefined macro may be used unless it is the argument to an `#ifdef' or `#ifndef' directive or the `defined()' operator

rule MC2.19.12 (required)

Reports any macro body that contains more than one occurrence of the `#' or `##' operators

rule MC2.19.13 (advisory)

Reports any use of the `#' and `##' preprocessor operators

rule MC2.19.14 (required)

The `defined' operator must be used in the form `defined(Macro_Id)' or `defined Macro_Id'

rule MC2.19.15 (required)

Any file that is the subject of an `#include' directive must have a mechanism to avoid the file being included more than once

rule MC2.19.16 (required)

Reports errors in the preprocessing directives even when excluded by conditional compilation

rule MC2.19.17 (required)

No preprocessor conditional constructs may span multiple files

rule MC2.20.1 (required)

No `#define' or `#undef' directive may be used on a reserved identifier, macro or function in the standard library or keyword

rule MC2.20.2 (required)

No declaration may use a reserved identifier, macro or function in the standard library

rule MC2.20.3 (required)

There must be appropriate checks of values passed to standard libraries that have restricted input domains

rule MC2.20.4 (required)

No standard function related to heap manipulation and dynamic memory allocation and deallocation may be used

rule MC2.20.5 (required)

Reports any use of the standard library error indicators

rule MC2.20.6 (required)

Reports any use of the standard library macro `offsetof'

rule MC2.20.7 (required)

Reports any use of the standard library macro `setjmp' and function `longjmp'

rule MC2.20.8 (required)

Reports the inclusion of the standard library header `signal.h' and any use of its macros or functions

rule MC2.20.9 (required)

Reports the inclusion of the standard library header `stdio.h' and any use of its macros or functions

rule MC2.20.10 (required)

Reports any use of the standard library functions `atof', `atoi' and `atol' provided by `stdlib.h'

rule MC2.20.11 (required)

Reports any use of the standard library functions `abort', `exit', `getenv' and `system' provided by `stdlib.h'

rule MC2.20.12 (required)

Reports the inclusion of the standard library header `time.h' and any use of its functions, members, structs or types provided by `time.h' or the function `wcsftime' provided by `wchar.h'

rule MC2.21.1 (required)

Reports if possible runtime unexpected behavior countermeasures are not documented

tool B.CBT

Tag reports using ECLAIR style comments

tool B.EXPLAIN

Explain user configuration

tool B.TOOLCHAIN

ECLAIR shall be able to retrieve toolchain information from the toolchain itself