Difference between revisions of "MISRA-C:2012 compliance"

From SEGGER Wiki
Jump to: navigation, search
(Created page with "MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association). embOS is MISRA-C:2012...")
 
m
Line 1: Line 1:
MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association).
+
MISRA C is a set of software development guidelines for the C programming language developed by [https://www.misra.org.uk/ MISRA] (''Motor Industry Software Reliability Association'').
embOS is MISRA-C:2012 compliant.
 
   
  +
[[embOS]] is MISRA-C:2012 compliant.
__TOC__
 
   
 
=== What needs to be done in order to be MISRA-C:2012 compliant? ===
 
=== What needs to be done in order to be MISRA-C:2012 compliant? ===
The official MISRA-C:2012 document "Guidelines for the use of the C language in critical systems" explains what needs to be done.
+
The official MISRA-C:2012 document, ''Guidelines for the use of the C language in critical systems'', explains what needs to be done in order to achive MISRA-C:2012 compliance.
  +
MISRA-C:2012 defines a set of guidelines which needs to be followed by the C program author.
 
These guidelines are split into Directives and Rules. All guidelines can be mandatory, required or advisory.
+
MISRA-C:2012 defines a set of guidelines that must to be followed by the C program author. These guidelines are split into two categories, ''Directives'' and ''Rules''.
Mandatory guidelines must not be violated. Required and advisory guidelines can be violated but every violation of a required guideline must be documented and justified in a MISRA document.
+
Furthermore, all guidelines are deemed to either be ''mandatory'', ''required'' or ''advisory''. Guidelines that are deemed mandatory must never be violated. Required and advisory guidelines, on the other hand, may be violated, but every violation of a required guideline must be documented and justified in a dedicated MISRA document.
  +
Most of the guidelines can be tested with a static analysis tool but not all.
 
Some guidelines can be checked with the C compiler or code review only.
+
Most of the guidelines can be tested with a static analysis tool. Other guidelines can be checked using a C compiler or manual code review only.
Therefore a C source code is not MISRA-C:2012 compliant when a static analysis tool does not complain about any issue.
+
Therefore, C source code may not actually be MISRA-C:2012 compliant just because a static analysis tool does not report any issue.
In any case a dedicated MISRA document is mandatory. The official MISRA-C:2012 document explains the structure of such a MISRA document.
+
Instead, a dedicated MISRA document is mandatory. The official MISRA-C:2012 document explains the structure of such MISRA document.
   
 
=== What part of an actual embOS port is MISRA compliant? ===
 
=== What part of an actual embOS port is MISRA compliant? ===
  +
Generally, embOS consists of three parts:
Basically embOS consists of three parts: the generic sources which are the same for all embOS ports, the core/compiler specific files and the board support package files.
 
  +
# generic sources, which are the same for all embOS ports,
The embOS MISRA compliance covers the embOS generic sources only.
 
If MISRA compliance for the core/compiler specific sources is required that can be done on request.
+
# core/compiler specific sources, and
  +
# board support package files.
The BSP files are usually not checked.
 
  +
  +
The embOS MISRA compliance covers the embOS generic sources only.<br />
  +
In case MISRA compliance for core/compiler specific sources is required, this needs to be requested at SEGGER.<br />
  +
The board support package files typcially are not checked to be MISRA compliant.
   
 
=== What static analysis tool is used? ===
 
=== What static analysis tool is used? ===
We use PC-lint V9 from Gimpel Software. The embOS source code contains Lint suppression comments for some MISRA guidelines.
+
We use ''PC-lint'' v9 by ''Gimpel Software''. The embOS source code contains respective Lint suppression comments for some MISRA guidelines.
That helps to know which MISRA-C:2012 guideline is violated and must be documented and justified. We treat advisory guideline like required guidelines which means we document and justify required and advisory guidelines.
+
These help in analyzing which MISRA-C:2012 guidelines were violated in the embOS source code and thus need to be justified in our MISRA document.
  +
Advisory guideline are treated the same as required guidelines, which means we document and justify both violations of the required guidelines and violations of the advisory guidelines.
   
 
=== I use another static analysis tool and it reports violations. How can I deal with that? ===
 
=== I use another static analysis tool and it reports violations. How can I deal with that? ===
If your static analysis tool reports MISRA-C:2012 violations it does not mean embOS is not MISRA-C:2012 compliant.
+
If your static analysis tool reports MISRA-C:2012 violations, this doesn't indicate embOS was not MISRA-C:2012 compliant.
It just means embOS does not contain suppression comments for your actual static analysis tool.
+
embOS merely does not contain suppression comments for your chosen static analysis tool.
It makes no sense to include according comments in the embOS source code for every existing MISRA checker.
+
With many different tools available, we cannot include according comments for all of these in the embOS source code.
  +
The easiest way to deal with it is to disable the MISRA checker for the embOS files. It is not necessary to check the embOS files again since that was already done by SEGGER.
 
  +
The easiest way to deal with this is to disable the chosen MISRA checker for all embOS files in your project. It is not necessary to check the embOS files for compliance, since that was already done by SEGGER.
   
 
=== How can I get the embOS MISRA-C:2012 document? ===
 
=== How can I get the embOS MISRA-C:2012 document? ===
If embOS is part of your application and you need to proof your application is MISRA-C:2012 compliant you can buy the embOS MISRA-C:2012 document from SEGGER.
+
If embOS is part of your application and you need to prove your application is MISRA-C:2012 compliant, you can buy the embOS MISRA-C:2012 document from SEGGER.

Revision as of 09:35, 28 April 2020

MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association).

embOS is MISRA-C:2012 compliant.

What needs to be done in order to be MISRA-C:2012 compliant?

The official MISRA-C:2012 document, Guidelines for the use of the C language in critical systems, explains what needs to be done in order to achive MISRA-C:2012 compliance.

MISRA-C:2012 defines a set of guidelines that must to be followed by the C program author. These guidelines are split into two categories, Directives and Rules. Furthermore, all guidelines are deemed to either be mandatory, required or advisory. Guidelines that are deemed mandatory must never be violated. Required and advisory guidelines, on the other hand, may be violated, but every violation of a required guideline must be documented and justified in a dedicated MISRA document.

Most of the guidelines can be tested with a static analysis tool. Other guidelines can be checked using a C compiler or manual code review only. Therefore, C source code may not actually be MISRA-C:2012 compliant just because a static analysis tool does not report any issue. Instead, a dedicated MISRA document is mandatory. The official MISRA-C:2012 document explains the structure of such MISRA document.

What part of an actual embOS port is MISRA compliant?

Generally, embOS consists of three parts:

  1. generic sources, which are the same for all embOS ports,
  2. core/compiler specific sources, and
  3. board support package files.

The embOS MISRA compliance covers the embOS generic sources only.
In case MISRA compliance for core/compiler specific sources is required, this needs to be requested at SEGGER.
The board support package files typcially are not checked to be MISRA compliant.

What static analysis tool is used?

We use PC-lint v9 by Gimpel Software. The embOS source code contains respective Lint suppression comments for some MISRA guidelines. These help in analyzing which MISRA-C:2012 guidelines were violated in the embOS source code and thus need to be justified in our MISRA document. Advisory guideline are treated the same as required guidelines, which means we document and justify both violations of the required guidelines and violations of the advisory guidelines.

I use another static analysis tool and it reports violations. How can I deal with that?

If your static analysis tool reports MISRA-C:2012 violations, this doesn't indicate embOS was not MISRA-C:2012 compliant. embOS merely does not contain suppression comments for your chosen static analysis tool. With many different tools available, we cannot include according comments for all of these in the embOS source code.

The easiest way to deal with this is to disable the chosen MISRA checker for all embOS files in your project. It is not necessary to check the embOS files for compliance, since that was already done by SEGGER.

How can I get the embOS MISRA-C:2012 document?

If embOS is part of your application and you need to prove your application is MISRA-C:2012 compliant, you can buy the embOS MISRA-C:2012 document from SEGGER.