MISRA C and C++ guidance
Use language restrictions, analysis and disciplined deviation to reduce ambiguity and defect risk in safety-related C and C++ software.
After this module, you should be able to:
- Explain what MISRA guidance can and cannot achieve
- Plan a project-specific compliance approach
- Use static analysis and review together
- Control deviations with technical justification
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-107 and TEA-203. Familiarity with C or C++ types, pointers and compilation is assumed.
MISRA guidance reduces avoidable language risk.
C and C++ give embedded developers powerful low-level control but include behaviours and constructs that are easy to misunderstand, implementation-dependent or difficult to analyse. MISRA guidance defines disciplined subsets and practices for critical systems.
Compliance is a project activity, not simply a tool report. The team must identify the applicable guideline edition and amendments, define scope, select analysis methods, address or deviate violations and retain a credible compliance record.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Compliance plan | Which guidelines, scope, tools and process apply? | Guideline compliance plan |
| Compiler control | Which implementation-defined behaviour and options are permitted? | Compiler and language configuration |
| Analysis | How will decidable and undecidable guidance be checked? | Static-analysis and review strategy |
| Deviation | When may a rule be violated and who approves it? | Deviation procedure and records |
| Reporting | How is final compliance and residual non-compliance shown? | Compliance summary |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Select the applicable MISRA publication, amendments and language version
- 2. Define translation units, generated code, third-party code and exclusions
- 3. Configure compiler warnings and qualified or validated analysis tools
- 4. Analyse continuously; resolve findings close to introduction
- 5. For necessary deviations, record circumstance, risk, evidence and approval
- 6. Report compliance for the released baseline and retain tool configurations
Worked application: memory-mapped register access
A low-level driver may need a construct that conflicts with general guidance. The team isolates it in one reviewed abstraction, documents the hardware necessity, analyses undefined-behaviour risk, verifies compiler behaviour and approves a narrow deviation rather than normalising the exception across the codebase.
Build evidence that explains the reasoning.
Guideline version, scope, process, tools and roles.
Rules, compiler options, suppressions and versions.
Findings linked to controlled source revisions.
Human assessment of guidance not fully automatable.
Rule, location, rationale, risk and approval.
Released baseline, status and justified exceptions.
Common failure patterns
One scanner is assumed to cover every guideline.
Warnings disappear without engineering assessment.
Thousands of findings are deferred until release.
Unreviewed generation and integration undermine the claim.
Define the language and guideline baseline explicitly
MISRA C and MISRA C++ are separate guideline sets for disciplined use of their respective languages. Select the edition, language version, compiler behaviour and project scope before configuring analysis. A tool option labelled MISRA is not a complete definition of the project’s coding policy.
Record which source is developed, adopted, generated or supplied by a third party and how it will be assessed. Do not silently exclude a driver because it produces many findings. Assess the applicable compliance approach and the evidence needed for code that was not developed under the project’s normal rules.
Keep the risk objective in view: predictable interpretation, controlled language features and reviewable behaviour. Coding rules support this objective, but they do not establish that the requirements are correct or that the integrated system meets its timing and safety needs.
Use findings and deviations to expose reasoning
An analyser can identify many rule violations, but some guidelines need manual review or contextual evidence. Maintain a coverage record explaining how each applicable guideline is checked and what the tool cannot determine. Review compiler extensions and implementation-defined behaviour that the product relies on.
A deviation is a controlled justification within the applicable framework, not a general permission to ignore inconvenient findings. It should identify the code and guideline, explain the need, assess the risk, describe compensating measures and receive the required approval. Some guideline categories do not permit deviation; use the selected MISRA compliance rules.
Distinguish false positives from accepted non-compliance. A false-positive disposition explains why the reported violation is not real; a deviation acknowledges the relevant departure and justifies its treatment. Both need enough context to survive a later code or tool change.
| Analysis record | Content to retain |
|---|---|
| Baseline | Guideline edition, language, compiler and configuration. |
| Coverage | Automated and manual checking responsibilities. |
| Finding | Location, interpretation, risk and disposition. |
| Deviation | Scope, rationale, controls, approval and revisit conditions. |
| Release summary | Applicable code, unresolved issues and supported claim. |
Check semantics beyond the warning count
Consider a copy operation that checks offset + length against a buffer capacity. If the addition can overflow, the check may accept an invalid range. A safer approach first validates offset against capacity and then compares length with capacity minus offset, using appropriate types and conversion rules.
This example illustrates why reviewing the mechanism matters more than suppressing a message. Test boundary values and retain the assumptions that make the check valid. A clean analyser report can still contain a wrong unit conversion, stale data policy or missing physical requirement.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Review an analyser suppression in a device driver
A driver casts an integer hardware address to a pointer. The finding is suppressed globally so that every similar cast disappears from the report.
- Explain why a global suppression is too broad for the intended justification.
- Define the evidence and scope of a controlled disposition.
- Identify what must be reconsidered after a compiler or MCU change.
Show the worked answer
The driver may need a platform-specific representation, but that does not justify unrelated casts elsewhere. Establish the exact address, alignment, access width, memory-mapped register semantics and compiler assumptions. Apply the selected guideline and compliance framework to determine whether and how the departure can be justified.
Limit the disposition to the approved code or pattern, retain review and verification evidence, and preserve visibility of other findings. Revisit it when the architecture, compiler, language settings or address map changes. Confirm that volatile access requirements and ordering are handled according to the platform contract; a cast alone establishes none of those properties.
Review criteria
- The disposition is narrowly scoped and technically justified.
- Platform assumptions and verification are explicit.
- Changes trigger reassessment instead of inheriting a blind suppression.
Check your understanding
Does zero analyser findings prove MISRA compliance?
No. Scope, guideline coverage, manual checks, deviations and the selected compliance framework also matter.
Can coding guidance replace system verification?
No. It reduces certain implementation risks; it does not prove the intended function, physical response or complete architecture.
Further learning
- MISRA COfficial MISRA information for C coding guidance.
- TEA-203 · Firmware and embedded software engineersFirmware structure, timing and reproducibility.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.