Main Content

MISRA C:2012 Compliance Information Summary Tables

Compliance Summary Tables

MathWorks® evaluates C code generated by Embedded Coder® from Simulink® and Stateflow® against the MISRA C:2012 coding standards. The results from this effort are available in these compliance summary tables. These tables identify:

  • Methods used to obtain compliance:

    • Compliant: Compliance to the rule/directive is achieved through adherence to the code generation process, modeling guidelines, or Model Advisor checks. When applicable, there are explanatory notes that provide information relevant to compliance methods or actions that you can perform to satisfy the directive or rule.

    • Deviation: The rule or directive is not compliant.

  • Whether the Polyspace® MISRA C:2012 Checker supports the rule or directive.

You can use these tables when preparing the MISRA C:2012 compliance statement for your project as required per section 5.3 of the MISRA C:2012 Guidelines for the Use of C Language in Critical Systems document. These tables align with the published MISRA C:2012 rule and directives tables.

"Implementation" MISRA C:2012 Directives

DirectiveCategoryCompliancePolyspace Support?
1.1Required

Compliant:

Yes, partially supported

"Compilation and Build" MISRA C:2012 Directives

DirectiveCategoryCompliancePolyspace Support?
2.1RequiredCompliantYes

"Requirements Traceability" MISRA C:2012 Directives

DirectiveCategoryCompliancePolyspace Support?
3.1Required

Compliant:

No

"Code Design" MISRA C:2012 Directives

DirectiveCategoryCompliancePolyspace Support?
4.1Required

Compliant:

Yes
4.3Required

Compliant:

No
4.6RequiredNot Applicable. See Explanatory Note for Directive 4.6 N/A
4.7Required

Compliant:

Deviation:

Yes[a]
4.10RequiredCompliantYes
4.11Required

Compliant:

Yes
4.12Required

Compliant:

No

[a] The Polyspace MISRA C:2012 Checker might flag Directive 4.7 as a Rule 17.7 violation (Polyspace Bug Finder) for user-defined functions when there is no knowledge about whether the return value contains error information.

"Standard C Environment" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
1.1RequiredCompliantYes
1.3RequiredCompliantYes

"Unused Code" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
2.1Required

Compliant:

Yes
2.2RequiredCompliantYes

"Comments" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
3.1Required

Compliant:

Yes
3.2RequiredCompliantYes

"Character Sets and Lexical Conventions" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
4.1RequiredCompliantYes

"Types" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
6.1Required

Compliant:

Yes
6.2Required

Compliant:

Yes

"Literals and Constants" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
7.4RequiredCompliantYes

"Declarations and Definitions" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
8.1RequiredCompliantYes
8.2RequiredCompliantYes
8.3RequiredCompliantYes
8.6RequiredCompliantYes
8.8RequiredCompliantYes
8.10RequiredCompliantYes
8.12Required

Compliant:

Yes

"Initialization" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
9.1Mandatory

Compliant:

Yes
9.4RequiredCompliantYes

"Pointer Type Conversion" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
11.1RequiredCompliantYes
11.2RequiredCompliantYes
11.3Required

Compliant:

Yes
11.6RequiredCompliantYes
11.7RequiredCompliantYes
11.8Required

Compliant:

Yes

"Expressions" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
12.2RequiredCompliantYes

"Side Effects" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
13.1RequiredCompliantYes
13.2Required

Compliant:

Yes
13.5Required

Compliant:

Deviation:

Yes
13.6MandatoryCompliantYes

"Control Statement Expressions" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
14.3Required

Compliant:

Yes

"Control Flow" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
15.6RequiredCompliantYes

"Functions" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
17.1RequiredCompliantYes
17.2Required

Compliant:

Yes
17.3MandatoryCompliantYes
17.4MandatoryCompliantYes
17.6MandatoryCompliantYes

"Pointers and Arrays" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
18.1RequiredCompliantYes
18.2RequiredCompliantYes
18.3RequiredCompliantYes
18.6RequiredCompliantYes
18.7RequiredCompliantYes
18.8RequiredCompliantYes

"Overlapping Storage" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
19.1MandatoryCompliantYes

"Preprocessing Directives" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
20.2RequiredCompliantYes
20.3RequiredCompliantYes
20.4RequiredCompliantYes
20.6RequiredCompliantYes
20.7RequiredCompliantYes
20.9RequiredCompliantYes
20.11RequiredCompliantYes
20.12RequiredCompliantYes
20.13RequiredCompliantYes
20.14RequiredCompliantYes

"Standard Libraries" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
21.1RequiredCompliantYes
21.2Required

Compliant:

Yes
21.3Required

Compliant:

Yes
21.4RequiredCompliantYes
21.6Required

Compliant:

Yes
21.7RequiredCompliantYes
21.8RequiredCompliantYes
21.9RequiredCompliantYes
21.10RequiredCompliantYes
21.11RequiredCompliantYes

"Resources" MISRA C:2012 Rules

RuleCategoryCompliancePolyspace Support?
22.1RequiredCompliantYes
22.2MandatoryCompliantYes
22.3RequiredCompliantYes
22.4MandatoryCompliantYes
22.5MandatoryCompliantYes
22.6MandatoryCompliantYes

Explanatory Notes

These explanatory notes are referenced from the MISRA C:2012 Compliance Information Summary Tables.

Explanatory Note for Directive 1.1

Information about the implementation-defined behavior for Embedded Coder is available in Configure Run-Time Environment Options . Compiler documentation is out of scope.

Character set encoding is managed by using the SavedCharacterEncoding model parameter. For additional information, including a list of supported character encodings, see slCharacterEncoding.

Configure the integer division method in the Model Configuration Parameters dialog box, on the Hardware Implementation pane. For additional information, see Configure Run-Time Environment Options

Embedded Coder generates #pragma when the user:

In both instances, you are responsible for documenting the intended use of the #pragma. For more information, see Control Data and Function Placement in Memory by Inserting Pragmas.

To enable the generation of bitfields:

  1. Select at least one of these model configuration parameters:

  2. Create a custom storage class with defined bitfields. See Create Storage Classes by Using the Custom Storage Class Designer for more information.

Explanatory Note for MISRA Directive 3.1

You can link requirements model elements. These links are included in the generated C code to provide traceability from a requirements document, to the model elements, and to the generated code. For additional information, see View Linked Requirements in Models and Blocks and Link Blocks and Requirements (Simulink Requirements).

Explanatory Note for Directive 4.1

You can use Polyspace Bug Finder™ to identify run-time errors and Polyspace Code Prover™ to prove the absence of run-time errors. For information, see:

Simulink Design Verifier can be used to detect design errors at the model level. For more information, see Run a Design Error Detection Analysis (Simulink Design Verifier).

Explanatory Note for Directive 4.3

Embedded Coder does not directly call assembly language code. You can add calls to assembly language functions through S-functions, code replacement libraries, Stateflow, and in MATLAB® blocks. These calls are documented as calls to External C Functions. In these cases, you are responsible for encapsulation.

For additional information, see:

Explanatory Note for Directive 4.6

Embedded Coder replaces basic data types with typedefs types, which are compatible with Directive 4.6. A guideline is not required because this behavior is default behavior in Embedded Coder. For additional information, see Replace and Rename Data Types to Conform to Coding Standards and Typedefs.

Explanatory Note for Directive 4.11

The requirements of this directive are satisfied by:

“Demonstrate statically that the input parameters can never take invalid values”.

You can use Polyspace Code Prover to analyze parameter ranges and prove the absence of run-time errors caused by out-of-range values. For additional information, see Run Polyspace Analysis on Code Generated with Embedded Coder (Polyspace Code Prover).

Explanatory Note for Rules 5.1, 5.2, 5.4, 5.5, 5.6, 5.7, and 5.8

Embedded Coder is configurable to limit the number of characters imposed by the implementation. For additional information, see Maximum identifier length.

To ensure unique names for different types of variables (local scope variables, global scope variables, macros, and so on), implement a naming convention. For additional information, see Model Configuration Parameters: Code Generation Symbols.

Explanatory Note for Rule 8.12

Embedded Coder supports the use of enumerated data. The file used to define the enumeration can be either manually or automatically generated. Files defining enumerations generated by Embedded Coder are compliant with MISRA C:2012 Rule 8.12 by design. If you manually create the definition file, you are responsible for ensuring compliance. For additional information, see Use Enumerated Data in Simulink Models.

Explanatory Note for Rules 10.1 and 10.2

Embedded Coder does not directly create data of type char. Data of char type can be introduced by user-defined S-functions, code replacement libraries, and custom storage classes. In this case, limit the usage of plain char to:

  • Plain char type for character values

  • Signed and unsigned char type for numeric values