Welcome to the MISRA discussion forum

MISRA Compliance:2016 and the associated document MISRA C:2004 Permits are now available as free downloads from the "Resources" section of this Bulletin Board.

MISRA Compliance sets out a framework for claiming compliance with MISRA coding guidelines including guidance on a robust and structured process for the use of deviations. It includes a mechanism for establishing pre-approved "permits" to help streamline the deviation process. It supersedes the compliance, deviation and process requirements previously published in various MISRA coding guidelines.

MISRA C:2004 Permits presents a number of deviation permits covering commonly-encountered use cases for use with the MISRA C:2004 guidelines. It should be used in conjunction with MISRA Compliance:2016, a companion document which describes the purpose of deviation permits and which sets out the principles by which the concept of MISRA Compliance is governed.

While it is widely considered that MISRA C provides best practice guidelines for the development of safety-related systems, the publication of ISO/IEC TS 17961:2013 "C Secure" has generated discussion on the applicability of MISRA C for secure applications.

A mapping of MISRA C coverage of the "C Secure" requirements shows that for freestanding applications, MISRA C already has excellent coverage of the "C Secure" requirements.  Additional guidelines are provided in this document to improve the coverage of the security concerns highlighted by the "C Secure" guidelines.

Attached Files

  MISRA C 2012 AMD1.pdf (Size: 205.95 KB / Downloads: 135)

While it is widely considered that MISRA C provides best practice guidelines for the development of safety-related systems, the publication of ISO/IEC TS 17961:2013 "C Secure" has generated discussion on the applicability of MISRA C for secure applications.

This document contains an updated mapping, following the publication of MISRA C:2012 Amendment 1, of MISRA C coverage of the "C Secure" requirements and shows that for freestanding applications, MISRA C has excellent coverage of the "C Secure" requirements.  The first edition has been superseded by this new edition and is no longer available.

Attached Files

  MISRA C 2012 Addendum 2 (Second Edition).pdf (Size: 114.28 KB / Downloads: 128)

This document presents a number of deviation permits covering commonly-encountered use cases for use with the MISRA C:2004 guidelines. It should be used in conjunction with MISRA Compliance:2016, a companion document which describes the purpose of deviation permits and which sets out the principles by which the concept of MISRA Compliance is governed.

The number of deviation permits within this document is expected to grow and it is possible that existing deviation permits may be revised. The document contains a table with a record of these changes.

The current release is Edition 1, published April 2016.

Attached Files

  MISRA C 2004 Permits (First Edition).pdf (Size: 254.91 KB / Downloads: 35)

This document is now superseded by MISRA Compliance:2020

MISRA Compliance sets out a framework for claiming compliance with MISRA coding guidelines including guidance on a robust and structured process for the use of deviations.  It includes a mechanism for establishing pre-approved "permits" to help streamline the deviation process. It supersedes the compliance, deviation and process requirements previously published in various MISRA coding guidelines.

Attached Files

  MISRA Compliance 2016.pdf (Size: 228.07 KB / Downloads: 43)

Hi everybody,

I am looking for a tool to do compliance checks for MISRA. Preferably with Eclipse IDE plug-in and not too expensive (

Dear MISRA team,

IMHO, this rule is missing one important exception: casting to [unsigned]char* to access individual bytes is well defined in the standard (chapter 3.9 § 2)
In fact, you find this exception in MISRA C 2012 Rule 11.3.

Hello,

I think this rule should be rephrased (or maybe split) for clarity, and giving some more examples.
Problems are:
1. As already mentioned - function overloading.

2. It is not clear whether static variables inside function are violating this rule:
void f1() { static int nFoo; }
void f2() { static int nFoo; }
I think it does not violate (also based on my exmaples from MISRA C-2012 Rule 5.9) but my static analysis tool, thinks it does.

3. Do static class members violate this rule?
class C1 { public: static int nNumOfItems; }
class C2 { public: static int nNumOfItems; }
I think it does not.

To my understanding, this rule comes to cover 2 cases (which should be properly explained in the rationale):
1. Hiding of identifier in an internal scope
2. Conusion of 2 global static identifiers with the same name (whose scope is actualy indipendantly limited to each .cpp file)

Thanks,
Udi.

Hi,
When the MISRA C:2012 Amendment 1 document will be available?

Regards,
Fahmi

The following code can be compiled.