ECLAIR
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