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
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.
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.