MISRA-C:2004 Compliance

group page_misra

This page describes MISRA-C:2012 compliance and deviations for the PDL.

MISRA stands for Motor Industry Software Reliability Association. The MISRA specification covers a set of 10 mandatory rules, 110 required rules and 39 advisory rules that apply to firmware design and has been put together by the Automotive Industry to enhance the quality and robustness of the firmware code embedded in automotive devices.

There are two types of deviations defined:

  • project deviations - deviations that are applicable for all PDL drivers

  • specific deviations - deviations that are applicable for the specific driver

Specific deviations are documented in the driver source code, close to the deviation occurrence. For each deviation a macro identifies the relevant rule or directive number, and reason.

Verification Environment

This section provides MISRA compliance analysis environment description.

Component

Name

Version

Test Specification

MISRA-C:2012 Guidelines for the use of the C language in critical systems

March 2013

MISRA Checking Tool

Coverity Static Analysis Tool

2020.03

Project Deviation

The list of deviated rules/directives is provided in the table below:

MISRA Rule/Directive

Deviation Class (Rule/Directive)

Rule Class (Required/Mandatory)

Rule/Directive Description

Description of Deviation(s)

1.1

D

R

Any implementation-defined behaviour on which the output of the program depends shall be documented and understood.

Violated because PDL supports GCC, IAR and MDK-ARM compilers. Refer to the compiler documentation for the compiler-specific behaviour.

4.1

D

R

Run-time failures shall be minimized.

Some drivers can contain redundant operations introduced because of generalized implementation approach.

1.1

R

R

The program shall contain no violations of the standard C syntax and constraints, and shall not exceed the implementation’s translation limits

PDL supports ISO:C99 standard.

1.3

R

R

There shall be no occurrence of undefined or critical unspecified behaviour.

This specific behavior is explicitly covered in rules 5.1, 21.1.

3.1

R

R

The character sequences /* and // shall not be used within a comment

Allow doxygen-style comments.

5.1

R

R

External identifiers shall be distinct

This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.

5.2

R

R

Identifiers declared in the same scope and name space shall be distinct

This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.

5.3

R

R

An identifier declared in an inner scope shall not hide an identifier declared in an outer scope

This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.

5.4

R

R

Macro identifiers shall be distinct

This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.

5.5

R

R

Identifiers shall be distinct from macro names

This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.

5.6

R

R

A typedef name shall be a unique identifier.

During the code analysis, the same source files are compiled multiple times with device-specific options. All typedef names are actually unique for each specific run.

5.8

R

R

Identifiers that define objects or functions with external linkage shall be unique.

During the code analysis, the same source files are compiled multiple times with device-specific options. All object and function identifiers are actually unique for each specific run.

11.1

R

R

Conversions shall not be performed between a pointer to a function and any other type

The cast from unsigned int to pointer does not have any unintended effect, as it is a consequence of the definition of a structure based on hardware registers.

11.2

R

R

Conversions shall not be performed between a pointer to an incomplete type and any other type

The cast from unsigned int to pointer does not have any unintended effect, as it is a consequence of the definition of a structure based on hardware registers.

11.6

R

R

A cast shall not be performed between pointer to void and an arithmetic type

The cast from unsigned int to pointer does not have any unintended effect, as it is a consequence of the definition of a structure based on hardware registers.

11.8

R

R

A cast shall not remove any const or volatile qualification from the type pointed to by a pointer

Drivers access hardware register by macro, which is used for both read and write access. In that case remove of const qualification does not have any unintended effect, as it is a consequence of the macro usage.

20.4

R

R

A macro shall not be defined with the same name as a keyword

There are some CMSIS-CORE defines are used for structure members definitions, that cannot be enclosed in parentheses.

21.1

R

R

#define and #undef shall not be used on a reserved identifier or reserved macro name

PDL header files contain preprocessor guard macros with leading underscores. PDL uses CMSIS macros with leading underscores and therefore inherits its MISRA violations.

21.2

R

R

A reserved identifier or macro name shall not be declared

PDL header files contain preprocessor guard macros with leading underscores. PDL uses CMSIS macros with leading underscores and therefore inherits its MISRA violations.