The text All code shall conform to ISO 9899:1990 Programming languages C, amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996 precedes each of the following messages:

No warnings if code is encapsulated in the following:

C++ comments are handled as comments but lead to a violation of this MISRA rule

Note: This rule cannot be annotated in the source code.

This rule violation is also raised when the character sequence /* inside a C++ comment.

Note: This rule cannot be annotated in the source code.

The checker uses internal heuristics to detect commented out code. For instance, characters such as #, ;, { or } indicate comments that might potentially contain code. These comments are then evaluated against other metrics to determine the likelihood of code masquerading as comment. For instance, several successive words without a symbol in between reduces this likelihood.

The checker does not flag the following comments even if they contain code:

The checker considers that these comments are meant for documentation purposes or entered deliberately with some forethought.

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

All identifiers (global, static and local) are checked.

For easier review, the rule checker shows all identifiers that have the same first 31 characters as one rule violation. You can see all instances of conflicting identifier names in the event history of that rule violation.

This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

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.

Assumes that rule 8.1 is not violated.

5.3

A typedef name shall be a unique identifier

{typedef name}'%s' should not be reused. (already used as {typedef name} at %s:%d)

Warning when a typedef name is reused as another identifier name.

5.4

A tag name shall be a unique identifier

{tag name}'%s' should not be reused. (already used as {tag name} at %s:%d)

Warning when a tag name is reused as another identifier name

This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

5.5

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

{static identifier/parameter name}’%s’ should not be reused. (already used as {static identifier/parameter name} with static storage duration at %s:%d)

Warning when a static name is reused as another identifier name

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.

{member name}'%s' should not be reused. (already used as {member name} at %s:%d)

Warning when an idf in a namespace is reused in another namespace

This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

5.7

No identifier name should be reused.

{identifier}'%s' should not be reused. (already used as {identifier} at %s:%d)

No violation reported when:

6.1

The plain char type shall be used only for the storage and use of character values

Only permissible operators on plain chars are '=', '==' or '!=' operators, explicit casts to integral types and '?' (for the 2nd and 3rd operands)

Warning when a plain char is used with an operator other than =, ==, !=, explicit casts to integral types, or as the second or third operands of the ? operator.

6.2

6.3

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

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

No warning is given in typedef definition.

6.4

Bit fields shall only be defined to be of type unsigned int or signed int.

Bit fields shall only be defined to be of type unsigned int or signed int.

6.5

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

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

No warning on anonymous signed int bitfields of width 0  - Extended to all signed bitfields of size <= 1 (if Rule 6.4 is violated).

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

Prototype visible at call must be complete.

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

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

If objects or functions are declared more than once their types shall be compatible.

Violations of this rule might be generated during the link phase.

This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

There shall be no definitions of objects or functions in a header file

Tentative definitions are considered as definitions. For objects with file scope, tentative definitions are declarations that:

Functions shall always be declared at file scope.

Function 'XX' should be declared at file scope.

This rule maps to ISO/IEC TS 17961 ID addrescape.

Restricted to explicit extern declarations (tentative definitions are ignored).

Polyspace considers that variables or functions declared extern in a non-header file violate this rule.

An identifier with external linkage shall have exactly one external definition.

The checker flags multiple definitions only if the definitions occur in different files.

No warnings appear on predefined symbols.

This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

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

Function/Variable XX should have internal linkage.

Assumes that 8.1 is not violated. No warning if 0 uses.

If your code does not contain a main function and you use options such as Variables to initialize (-main-generator-writes-variables) with value custom to explicitly specify a set of variables to initialize, the checker does not flag those variables. The checker assumes that in a real application, the file containing the main must initialize the variables in addition to any file that currently uses them. Therefore, the variables must be used in more than one translation unit.

This checker is deactivated in a default Polyspace as You Code analysis. See Checkers Deactivated in Polyspace as You Code Analysis (Polyspace Access).

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

static storage class specifier should be used on internal linkage symbol XX.

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

Size of array 'XX' should be explicitly stated.

All automatic variables shall have been assigned a value before being used.

Polyspace reports a violation of this rule if your code contains these issues:

Braces shall be used to indicate and match the structure in the nonzero initialisation of arrays and structures.

Braces shall be used to indicate and match the structure in the nonzero initialization of arrays and structures.

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

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

The value of an expression of integer type shall not be implicitly converted to a different underlying type if:

ANSI C base types order (signed char, short, int, long) defines that T2 is wider than T1 if T2 is on the right hand of T1 or T2 = T1. The same interpretation is applied on the unsigned version of base types.

An expression of bool or enum types has int as underlying type.

Plain char may have signed or unsigned underlying type (depending on Polyspace target configuration or option setting).

The underlying type of a simple expression of struct.bitfield is the base type used in the bitfield definition, the bitfield width is not token into account and it assumes that only signed | unsigned int are used for bitfield (Rule 6.4).

No violation reported when:

No violation reported when the following are all true:

No violation reported on operations involving pointers.

Conversions of constants are not reported for these cases to avoid flagging too many violations. If the constant can be represented in both the original and converted type, the conversion is less of an issue.

The value of an expression of floating type shall not be implicitly converted to a different type if

ANSI C base types order (float, double) defines that T2 is wider than T1 if T2 is on the right hand of T1 or T2 = T1.

No violation reported when:

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

Complex expression of underlying type XX may only be cast to narrower integer type of same signedness, however the destination type is XX.

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

Complex expression of XX type may only be cast to narrower floating type, however the destination type is XX.

ANSI C base types order (float, double) defines that T1 is narrower than T2 if T2 is on the right hand of T1 or T2 = T1. 

If the bitwise operator ~ and << are applied to an operand of underlying type unsigned char or unsigned short, the result shall be immediately cast to the underlying type of the operand

Bitwise [<<|~] is applied to the operand of underlying type [unsigned char|unsigned short], the result shall be immediately cast to the underlying type.

The “U” suffix shall be applied to all constants of unsigned types

No explicit 'U suffix on constants of an unsigned type.

 Warning when the type determined from the value and the base (octal, decimal or hexadecimal) is unsigned and there is no suffix u or U.

For example, when the size of the int and long int data types is 32 bits, the coding rule checker will report a violation of rule 10.6 for the following line:

int a = 2147483648;

There is a difference between decimal and hexadecimal constants when int and long int are not the same size.

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

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

Casts and implicit conversions involving a function pointer.

Casts or implicit conversions from NULL or (void*)0 do not give any warning.

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

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

There is also a warning on qualifier loss

This rule maps to ISO/IEC TS 17961 ID alignconv.

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

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

Exception on zero constant. Extended to all conversions

This rule maps to ISO/IEC TS 17961 ID alignconv.

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

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

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

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

Extended to all conversions

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

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

Rule 12.2 check assumes that no assignment in expressions that yield a Boolean values (rule 13.1).

The expression is a simple expression of symbols. i = i++; is a violation, but tab[2] = tab[2]++; is not a violation.

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

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

No warning on volatile accesses

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

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

No warning on volatile accesses

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

During preprocessing, violations of this rule are detected on the expressions in #if directives.

Allowed exception on associatively (a && b && c), (a || b || c).

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

The operand of a logical operator should be a Boolean data type. Although the C standard does not explicitly define the Boolean data type, the standard implicitly assumes the use of the Boolean data type.

Some operators may return Boolean-like expressions, for example, (var == 0).

Consider the following code:

unsigned char flag;
if (!flag)

The rule checker reports a violation of rule 12.6:

Operand of '!' logical
operator should be 
effectively Boolean.

To be compliant with rule 12.6, the code must be rewritten either as

if (!( flag != 0))

if (flag == 0)

The use of the option -boolean-types may increase or decrease the number of warnings generated.

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

The underlying type for an integer is signed when:

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 numbers that are manipulated in preprocessing directives are 64 bits wide so that valid shift range is between 0 and 63

Check is also extended onto bitfields with the field width or the width of the base type when it is within a complex expression

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

The underlying type for an integer is signed when:

The comma operator shall not be used.

The comma operator shall not be used.

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

Warning when:

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

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

Warning when ++ or -- operators are not used alone.

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

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

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

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

No warning is given on integer constants. Example: if (2)

The use of the option -boolean-types may increase or decrease the number of warnings generated.

Boolean operations whose results are invariant shall not be permitted

During compilation, the checker covers comparisons with at least one constant operand. Some violations of this rule are reported through the Dead code and Useless if checkers.

The rule violation appears when you check whether an enum variable value lies between its lower and upper bound. The violation appears even if you increment or decrement the variable outside its bounds, for instance, in this for loop condition:

enum ec {RED, BLUE, GREEN} 
    col;
for(col=RED; col<=GREEN; 
    col++)
{}

enum ec {RED, BLUE, GREEN} 
   col;
for(col=RED; (int)col<=GREEN;
    col++ )
{}

There shall be no unreachable code.

All non-null statements shall either have at least one side effect however executed, or cause control flow to change

All non-null statements shall either:

Before preprocessing, a null statement shall 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.

We assume that a ';' is a null statement when it is the first character on a line (excluding comments). The rule is violated when:

The goto statement shall not be used.

The goto statement shall not be used.

The continue statement shall not be used.

The continue statement shall not be used.

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

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

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

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

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

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

All if else if constructs should contain a final else clause.

All if else if constructs should contain a final else clause.

The MISRA C switch syntax shall be used.

switch statements syntax normative restrictions.

Warning on declarations or any statements before the first switch case.

Warning on label or jump statements in the body of switch cases.

On the following example, the rule is displayed in the log file at line 3:

1 ...
2 switch(index) {
3  var = var + 1; 
// RULE 15.0 
// violated
4case 1: ...

The code between switch statement and first case is checked as dead code by Polyspace. It follows ANSI standard behavior.

This rule is not considered as a required rule in the MISRA C:2004 rules for generated code. In generated code, if you find a violation of rule 15.0 that does not simultaneously violate a later rule in this group, justify the violation with appropriate comments.

A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement

A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement

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

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

Warning for each non-compliant case clause.

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

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

A switch expression should not represent a value that is effectively Boolean

A switch expression should not represent a value that is effectively Boolean

The use of the option -boolean-types may increase the number of warnings generated.

Every switch statement shall have at least one case clause

Every switch statement shall have at least one case clause

Functions shall not be defined with variable numbers of arguments.

Function XX should not be defined as varargs.

Functions shall not call themselves, either directly or indirectly.

Function %s should not call itself.

The checker reports each function that calls itself, directly or indirectly. Even if several functions are involved in one recursion cycle, each function is individually reported.

You can calculate the total number of recursion cycles using the code complexity metric Number of Recursions.

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

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

Assumes Rule 8.6 is not violated.

Assumes that rules 8.8, 8.1 and 16.3 are not violated.

All occurrences are detected.

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

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

Definitions are also checked.

Assumes that rule 8.1 is not violated.

This rule maps to ISO/IEC TS 17961 ID argcomp.

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.

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

Warning if a non-const pointer parameter is either not used to modify the addressed object or is passed to a call of a function that is declared with a const pointer parameter.

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

Missing return value for non-void function XX.

Warning when a non-void function is not terminated with an unconditional return with an expression.

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

Function identifier XX should be preceded by a & or followed by a parameter list.

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

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

The checker flags functions with non-void return if the return value is not used or not explicitly cast to a void type.

The checker does not flag the functions memcpy, memset, memmove, strcpy, strncpy, strcat, strncat because these functions simply return a pointer to their first arguments.

Pointer arithmetic shall only be applied to pointers that address an array or array element.

Pointer arithmetic shall only be applied to pointers that address an array or array element.

>, >=, <, <= shall not be applied to pointer types except where they point to the same array.

>, >=, <, <= shall not be applied to pointer types except where they point to the same array.

Warning on:

Warning when assigning address to a global variable, returning a local variable address, or returning a parameter address.

This rule maps to ISO/IEC TS 17961 ID accfree.

All structure or union types shall be complete at the end of a translation unit.

All structure or union types shall be complete at the end of a translation unit.

Warning for all incomplete declarations of structs or unions.

An object shall not be assigned to an overlapping object.

Unions shall not be used

Unions shall not be used.

#include statements in a file shall only be preceded by other preprocessors directives or comments

A message is displayed when a #include directive is preceded by other things than preprocessor directives, comments, spaces or “new lines”.

Nonstandard characters should not occur in header file names in #include directives

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

Macro '<name>' does not expand to a compliant construct.

We assume that a macro definition does not violate this rule when it expands to:

Macros shall not be #defined and #undefd within a block.

#undef shall not be used.

#undef shall not be used.

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

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

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

Macro argument shall not look like a preprocessing directive.

This rule is detected as violated when the '#' character appears in a macro argument (outside a string or character constant)

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 ##.

Parameter instance shall be enclosed in parentheses.

If x is a macro parameter, the following instances of x as an operand of the # and ## operators do not generate a warning: #x, ##x, and x##. Otherwise, parentheses are required around x.

The software does not generate a warning if a parameter is reused as an argument of a function or function-like macro. For example, consider a parameter x. The software does not generate a warning if x appears as (x) or (x, or ,x) or ,x,.

All macro identifiers in preprocessor directives shall be defined before use, except in #ifdef and #ifndef preprocessor directives and the defined() operator.

'<name>' is not defined.

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

More than one occurrence of the # or ## preprocessor operators.

The # and ## preprocessor operators should not be used

Message on definitions of macros using # or ## operators

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

'defined' without an identifier.

When a header file is formatted as,

#ifndef <control macro>
#define <control macro> 
<contents> #endif

or,

#ifndef <control macro>
#error ...
#else 
#define <control macro> 
<contents> #endif

it is assumed that precautions have been taken to prevent multiple inclusions. Otherwise, a violation of this MISRA rule is detected.

Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor.

directive is not syntactically meaningful.

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

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

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

Identifier XX should not be used.

In case a macro whose name corresponds to a standard library macro, object or function is defined, the rule that is detected as violated is 20.1.

Tentative definitions are considered as definitions. For objects with file scope, tentative definitions are declarations that:

The validity of values passed to library functions shall be checked.

Validity of values passed to library functions shall be checked

Warning for argument in library function call if the following are all true:

The library function can be one of the following : sqrt, tan, pow, log, log10, fmod, acos, asin, acosh, atanh, or atan2.

You might be using a custom library of mathematical functions. If a custom library function have the same domain and range as another function from the standard library, you can extend this checker to check the custom library function. See Extend Bug Finder Checkers for Standard Library Functions to Custom Libraries.

A default Bug Finder analysis might not raise a violation of this rule when the input values are unknown and only a subset of inputs can cause an issue. To check for violations caused by specific system input values, run a stricter Bug Finder analysis. See Extend Bug Finder Checkers to Find Defects from Specific System Input Values.

By default, a Bug Finder analysis does not recognize infinities and NaNs. Operations that results in infinities and NaNs might be flagged as defects. To handle infinities and NaN values in your code, use the option Consider non finite floats (-allow-non-finite-floats).

Dynamic heap memory allocation shall not be used.

In case the dynamic heap memory allocation functions are actually macros and the macro is expanded in the code, this rule is detected as violated. Assumes rule 20.2 is not violated.

The error indicator errno shall not be used

The error indicator errno shall not be used

Assumes that rule 20.2 is not violated

The macro offsetof, in library <stddef.h>, shall not be used.

Assumes that rule 20.2 is not violated

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

In case the longjmp function is actually a macro and the macro is expanded in the code, this rule is detected as violated. Assumes that rule 20.2 is not violated

The signal handling facilities of <signal.h> shall not be used.

In case some of the signal functions are actually macros and are expanded in the code, this rule is detected as violated. Assumes that rule 20.2 is not violated

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

In case the input/output library functions are actually macros and are expanded in the code, this rule is detected as violated. Assumes that rule 20.2 is not violated

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

In case the atof, atoi and atoll functions are actually macros and are expanded, this rule is detected as violated. Assumes that rule 20.2 is not violated

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

In case the abort, exit, getenv and system functions are actually macros and are expanded, this rule is detected as violated. Assumes that rule 20.2 is not violated

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

In case the time handling functions are actually macros and are expanded, this rule is detected as violated. Assumes that rule 20.2 is not violated

Minimization of runtime failures shall be ensured by the use of at least one of:

No reliance shall be placed on undefined or unspecified behavior

Not statically checkable unless the data dynamic properties is taken into account

Multiple compilers and/or languages shall only be used if there is a common defined interface standard for object code to which the language/compilers/assemblers conform.

It is a process rule method.

The compiler/linker/Identifiers (internal and external) shall not rely on significance of more than 31 characters. Furthermore the compiler/linker shall be checked to ensure that 31 character significance and case sensitivity are supported for external identifiers.

To observe this rule, check your compiler documentation.

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

To observe this rule, check your compiler documentation.

All usage of implementation-defined behavior shall be documented.

To observe this rule, check your compiler documentation. Error detection is based on undefined behavior, according to choices made for implementation- defined constructions.

The character set and the corresponding encoding shall be documented.

To observe this rule, check your compiler documentation.

The implementation of integer division in the chosen compiler should be determined, documented and taken into account.

To observe this rule, check your compiler documentation.

The implementation-defined behavior and packing of bitfields shall be documented if being relied upon.

To observe this rule, check your compiler documentation.

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

To observe this rule, check your compiler documentation.

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

"purpose" is functional design issue.