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

MISRA stands for Motor Industry Software Reliability Association.

Warning: PDL Alpha release does not have a full compliance to MISRA-C:2012

The MISRA specification covers a set of guidelines classified as a "rule" or a "directive" 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:2012 Guidelines for the use of the C language in critical systems	March 2013
MISRA Checking Tool	Coverity	2018.12

Project Deviation

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

MISRA rule	Rule Class (Required/Advisory)	Rule Description	Description of Deviation(s)
Dir 4.9	A	A function should be used in preference to a function-like macro where they are interchangeable	Deviated since function-like macros are used to allow more efficient code.
Rule 1.2	A	Language extensions should not be used.	PDL supports ISO:C99 standard.
Rule 2.3	A	A project should not contain unused type declarations.	PDL is a library that provides API to the hardware. The type is part of API, which is defined for application-level only.
Rule 2.4	A	A project should not contain unused tag declarations.	PDL is a library that provides API to the hardware. The tag like enums ; is part of API, which are defined for application-level only.
Rule 2.5	A	A project should not contain unused macro declarations.	PDL is a library that provides API to the hardware. The macro is part of API, which is defined for application-level only.
Rule 3.1	R	The character sequences /* and // shall not be used within a comment.	Using of the special comment symbols is need for Doxygen comment support, it does not have any impact.
Rule 5.5	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.
Rule 8.7	A	Functions and objects should not be defined with external linkage if they are referenced in only one translation unit.	PDL is a library that provides API to the hardware. The functions and objects with external linkage are part of API, which are defined for application-level only.
Rule 11.4	A	A conversion should not be performed between a pointer to object and an integer type.	The cast from unsigned int to pointer does not have an unintended effect, as it is a consequence of the definition of a structure based on hardware registers.
Rule 11.8	R	A cast shall not remove any const or volatile qualifications from the type pointed 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.
Rule 18.4	A	The +,-,+= and -= operators should not be applied to an expression of pointer type.	There are several instances of pointer arithmetic in drivers. They cannot be avoided, so are manually checked and reviewed to be safe.
Rule 21.1	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.
Rule 21.2	R	A reserved identifier or macro name shall not be declared.	Some PDL macros begin with '__'. The PDL is verified with various compilers and avoids conflicts with the standard library names.