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

MISRA stands for Motor Industry Software Reliability Association. The MISRA specification covers a set of 122 mandatory rules and 20 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

Verification Environment

This section provides MISRA compliance analysis environment description.

Component	Name	Version
Test Specification	MISRA-C:2004 Guidelines for the use of the C language in critical systems	October 2004
MISRA Checking Tool	Programming Research QA C source code analyzer for Windows	9.4.1
MISRA Checking Tool	Programming Research QA C MISRA-C:2004 Compliance Module (M2CM)	3.3.3

Project Deviation

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

MISRA rule	Rule Class (Required/Advisory)	Rule Description	Description of Deviation(s)
1.1	R	This rule states that code shall conform to C ISO/IEC 9899:1990 standard.	PDL supports ISO:C99 standard.
1.2	R	No reliance shall be placed on undefined or unspecified behaviour.	This specific behavior is explicitly covered in rules 5.1, 20.1.
1.3	R	Multiple compilers and/or languages shall be used only if there is a common defined interface standard for object code to which the languages/compilers/assemblers conform.	Violated because PDL supports GCC, IAR and MDK-ARM compilers.
3.1	R	All usage of implementation-defined behaviour shall be documented.	Refer to the compiler documentation for the compiler-specific behaviour.
5.1	R	Identifiers (internal and external) shall not rely on the significance of more than 31 characters.	This rule applies to ISO:C90 standard. PDL conforms to ISO:C99 that does not require this limitation.
11.3	R	This rule states that cast should not be performed between a pointer type and an integral 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.5	R	A cast shall not be performed that removes any const or volatile qualification from the type addressed 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.
17.4	R	Array indexing shall be the only allowed form of pointer arithmetic.	There are several instances of pointer arithmetic in drivers. They cannot be avoided, so are manually checked and reviewed to be safe.
19.4	R	Macros shall only expand to a limited set of constructs.	There are some CMSIS-CORE defines are used for structure members definitions, that cannot be enclosed in parentheses.
19.7	A	A function should be used in preference to a function-like macro.	Deviated since function-like macros are used to allow more efficient code.
20.1	R	Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined.	PDL header files contain preprocessor guard macros with leading underscores. PDL uses CMSIS macros with leading underscores and therefore inherits its MISRA violations.
20.2	R	The names of standard library macros, objects and functions shall not be reused.	Some PDL macros begin with '__'. The PDL is verified with various compilers and avoids conflicts with the standard library names.
21.1	R	Minimization 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.	Some drivers can contain redundant operations introduced because of generalized implementation approach.