MISRA C & AUTOSAR C++: Coding Standard Compliance Tools

MISRA C and MISRA C++ are guideline sets for writing C and C++ that behaves predictably in critical systems. AUTOSAR C++14 is a set of C++14 guidelines published by AUTOSAR, which reused many MISRA C++:2008 rules alongside rules of its own. AUTOSAR no longer maintains it, and MISRA C++:2023 has since brought the MISRA C++:2008 and AUTOSAR C++14 work together into one guideline set for C++17.

Adopting the guidelines is only part of the job. MISRA also publishes MISRA Compliance:2020, which sets out what a claim of compliance means, what evidence a supplier hands to an acquirer, and how the tools used to check the code fit into that evidence.

This page summarises those documents in our own words and points to the sections where the detail lives. It is not a substitute for them: the MISRA guidelines and MISRA Compliance are available from the MISRA website, and any project claiming compliance needs its own copies. Tool capabilities and certifications are attributed to the vendor that publishes them.

Which document applies to your project

MISRA C editions and current status

The MISRA C page on the MISRA website lists five editions with the following publication dates.

MISRA C:2025 is the current edition. MISRA describes it as an incremental update that keeps support for C11, C18 and earlier versions of the language, and its product page marks MISRA C:2023 as no longer current.

What changed in MISRA C:2025

MISRA C:2025 is the first edition to renumber any existing rules. Only a handful of guidelines are affected, and the numbering of the rest is unchanged. Appendix J of MISRA C:2025 lists the changes, including the new rules. The renumbered, removed and re-categorised guidelines are:

• Rule 1.2 becomes Directive 1.2
• Rule 21.1 becomes Rule 20.15
• Rule 21.2 becomes Rule 5.10
• Rules 17.5 and 17.6 are combined as Rule 17.5
• Rule 11.7 is removed
• Rule 11.4 becomes Required
• Rule 15.5 becomes Disapplied

A tool configuration, deviation record or guideline enforcement plan written against MISRA C:2023 may need re-mapping for these changes. Because MISRA C:2025 also adds new rules, it needs reviewing in any case rather than being carried forward unchanged.

MISRA C++:2008 and MISRA C++:2023

MISRA C++:2008 was launched in June 2008. According to the MISRA C++ page, MISRA C++:2023 was published in October 2023, is the current edition, and specifically targets C++17 as defined by ISO/IEC 14882:2017. Like MISRA C, it contains both directives and rules.

AUTOSAR C++14

AUTOSAR C++14 is a standalone guideline set for C++14 (ISO/IEC 14882:2014). It contains AUTOSAR’s own rules, numbered with an “A” prefix, and rules taken from MISRA C++:2008, numbered with an “M” prefix. Each rule is either Required or Advisory. A Required rule has to be followed unless a formal deviation is raised, while an Advisory rule can be departed from without one.

The document also classifies each rule by how far static analysis can enforce it (automated, partially automated or non-automated) and by where the rule is meant to be applied. Rules that static analysis cannot fully enforce have to be covered by review or other manual activities.

AUTOSAR has marked the AUTOSAR C++14 Guidelines obsolete, and release 19-03 is the final version. Existing programmes built on it can still be checked against it. The choice for new work depends on the language version the project uses: for C++17, MISRA C++:2023 is the current MISRA guideline set.

How MISRA classifies guidelines

Every MISRA guideline is either a rule or a directive. A rule is defined entirely in terms of the source code, so whether code complies with it can in principle be judged from the code alone. A directive cannot be judged from the source code alone. Checking it may also need design documentation, requirements or process records, so a tool can help but may not settle it on its own.

Each guideline in MISRA C and MISRA C++:2023 is given a category by the guidelines themselves. Mandatory guidelines must never be violated. Required guidelines may only be violated when a deviation is in place. Advisory guidelines should be followed as far as reasonably practical, and departures from them do not need a deviation. MISRA C:2025 also uses the Disapplied category, described below, for Rule 15.5.

Rules also carry two properties that matter when choosing and configuring a tool:

• Analysis scope. A rule is either checkable within a single translation unit or needs the whole system to be analysed. A system-scope rule cannot be checked by looking at one source file at a time.
• Decidability. A rule is decidable when a tool can always give a definite yes or no answer about compliance, and undecidable when it cannot. For undecidable rules, tools differ in how well they separate definite violations from possible ones, and how well they avoid both false positives and false negatives.

What a credible compliance claim requires

MISRA Compliance:2020 applies to MISRA C and MISRA C++ alike, and a claim of compliance with either is only credible when the code was developed under a process that follows it. Its main requirements are summarised below.

Compliance belongs to a project. Section 4.1 makes clear that compliance is claimed for a project, not for an organisation. A company cannot be MISRA compliant, but a project can. There is also no such thing as MISRA certification.

Guideline enforcement plan (GEP). Section 3.3 requires a plan that lists every guideline and says how compliance with each one is checked: by analysis tools, the compiler, manual review, or a combination. For each tool, the plan records its version, configuration and options, together with evidence that it detects violations of the guidelines it is credited with. A guideline that a tool does not fully enforce may need a manual process, and any such process is recorded in the plan as well.

Deviations. A Required guideline may only be violated when a deviation supports it. The deviation record (section 4.2) explains why the violation is needed and why it is acceptable, including the precautions that go with it, so that an acquirer or assessor can judge it. Because the record describes the circumstances in which the violation is acceptable, it can cover a single instance or every instance that meets those circumstances. Section 4.4 sets out when a deviation must not be raised, such as for convenience alone, and allows one to be approved for one or more of the four reasons it lists.

Deviation permits. Section 4.3 describes deviation permits, which define an approved use case that deviation records can then draw on. A permit can come from MISRA, the acquirer or the supplier.

Guideline re-categorisation plan (GRP). Section 5.1 requires the acquirer and supplier to agree, at the start of a project, a plan that sets how the guidelines apply. It adds a Disapplied category, which only an Advisory guideline can be moved to. A Mandatory guideline cannot be re-categorised, a Required guideline can only be raised to Mandatory, and an Advisory guideline can be raised to Required or Mandatory.

Guideline compliance summary (GCS). At the end of the project, section 7.3 asks for a summary recording the compliance level claimed for each guideline: Compliant, Deviations, Violations or Disapplied. Which levels may be claimed depends on the guideline’s category.

Project delivery. Section 7.4 lists what the supplier makes available to the acquirer, including the GEP, the GCS and the deviation material. Section 7.1 also asks the supplier to keep records showing that the people doing the MISRA work have the relevant skills and experience.

What MISRA Compliance says about tools

Section 2.6 of MISRA Compliance:2020 is the part that bears on tool selection. In summary:

• Static analysis. In practice, checking code against the guidelines needs at least one static analysis tool, and it has to analyse the whole program rather than one file at a time. Because tools differ in what they emphasise, more than one may be needed (section 2.6.2). No tool can find every violation without also reporting false positives (sections 2.6.2 and 3.5).
• Compiler validation. Evidence that the compiler conforms to the language standard should come from its developer, or failing that from independent validation, for example with a conformance test suite (section 2.6.1).
• Tool qualification. Some process standards, including IEC 61508, ISO 26262 and DO-178, require compilers and static analysis tools to be qualified in some situations (section 2.6.3). See the ISO 26262, IEC 61508 and DO-178C pages for how the GSAS toolchain maps to those standards.
• Configuration for the real target. The compiler has to be configured for the language version and target the project actually uses, and the analyser has to be configured to match the compiler’s implementation choices, such as the sizes of the integer types (sections 2.6.4 and 2.6.5).
• Metrics. MISRA recommends collecting metrics with tools but leaves the thresholds to the industry, organisation or project (section 2.5).
• The Standard Library. Standard Library code does not have to comply with the guidelines, because it is part of the implementation, but the project still has to show that any violations in it do not compromise safety or security. Guidelines that depend on the interface in the standard headers still apply, and a project may choose to treat the library like any other adopted code (section 6.6).

Mapping the GSAS toolchain to the obligations

GSAS Micro Systems is an engineering partner for the vendors below. The table maps each tool to the obligation it helps with, rather than claiming one tool is better than another.

Perforce QAC and Klocwork

Both tools come from Perforce and both are available through GSAS. Perforce’s datasheets list MISRA C:2004, MISRA C:2012, MISRA C:2023, MISRA C:2025, MISRA C++:2008, MISRA C++:2023, AUTOSAR C++14 and JSF AV C++ for each of them. A standard appearing on a datasheet says the tool supports it. It does not say which guidelines the tool enforces fully, which it enforces partly, and which it leaves to review, and that per-guideline detail is what the guideline enforcement plan needs. Ask Perforce or GSAS for it for the edition your project uses.

In practice the choice turns on what else the codebase needs. Perforce QAC is focused on C, C++ and Rust, with quality-oriented standards such as Barr-C and HIC++. Klocwork adds five more languages and a wider security standard list (OWASP Top 10, PCI DSS, DISA STIG v6), which suits a large, multi-language codebase analysed in a CI/CD pipeline. Perforce also states that its “safety experts actively shape MISRA and Rust standards (currently in development)”.

Perforce QAC is the current name for the product previously sold as Helix QAC, and before that as PRQA QA·C and QA·C++.

Undecidable rules

For undecidable rules, a tool reports possible violations as well as definite ones, and an engineer has to review the possible ones. How much of that review a project faces depends on the tool and on the code, which is one reason MISRA Compliance asks for evidence of what a tool detects rather than relying on a vendor’s description.

MISRA compliance is not dynamic verification

MISRA Compliance:2020 sets no structural coverage or unit test requirement. Conforming to the guidelines says nothing about whether the code does the right thing. Where a project also has to demonstrate dynamic verification, that is a separate toolchain: Razorcat TESSY performs unit, module and integration testing for embedded C and C++ with C0, C1, decision, MC/DC and MCC coverage, and Razorcat CTE supports systematic test case design using the Classification Tree Method.

Frequently asked questions

Should a new project adopt MISRA C:2023 or MISRA C:2025?

MISRA C:2025 is the current edition, and MISRA marks MISRA C:2023 as no longer current. Where a contract already names MISRA C:2023, note that only a handful of guidelines were renumbered, removed or re-categorised in MISRA C:2025, and that new rules were added. Appendix J of MISRA C:2025 lists the changes, and tool configurations, deviation records and the guideline enforcement plan should be reviewed against it.

Is AUTOSAR C++14 still maintained?

No. AUTOSAR has marked the AUTOSAR C++14 Guidelines obsolete, and release 19-03 is the final version. Existing programmes can still be checked against it, and both Perforce QAC and Klocwork list AUTOSAR C++14 support. MISRA C++:2023, which brings the MISRA C++:2008 and AUTOSAR C++14 work together, is the current MISRA guideline set for projects using C++17.

What is the difference between a rule and a directive?

A rule is defined in terms of the source code alone, so compliance can in principle be judged from the code, subject to the decidability limits above. A directive also depends on things outside the code, such as design documentation, requirements or process, so a tool may only partly support checking it. For any guideline that a tool does not fully enforce, rule or directive, the guideline enforcement plan records the manual review that covers it.

Can a company or a tool be MISRA certified?

No. There is no such thing as MISRA certification. A project can claim compliance with MISRA, but neither a company nor a tool can be MISRA certified. Tool vendors may hold certification from an independent assessor for functional safety standards, as Perforce does from TÜV SÜD for Perforce QAC and Klocwork, but that is a different thing.

What do we have to hand over at the end of the project?

Section 7.4 of MISRA Compliance:2020 lists what the supplier makes available to the acquirer, including the guideline enforcement plan, the guideline compliance summary and the deviation material. The closing document is a guideline compliance summary that records a compliance level per guideline, not a free-form compliance report.

Does the Standard Library have to be MISRA compliant?

No, but the project has to show that any violations in it do not compromise safety or security. Guidelines that depend on the interface in the standard headers still apply, and a project may choose to treat the Standard Library like any other adopted code. Library qualification tooling such as Solid Sands SuperGuard supports that route.

Does MISRA compliance mean the software is free of defects?

No. The MISRA guidelines constrain how the language is used. They do not address functional correctness, and MISRA Compliance:2020 sets no structural coverage or testing requirement. Guideline conformance is one layer, alongside compiler and library qualification, dynamic testing with structural coverage, integration testing and review.

MISRA and AUTOSAR support across India

GSAS Micro Systems works with 25 technology partners. Four of them carry the tooling this page describes: Perforce for static analysis, Solid Sands for compiler and library qualification, Razorcat for dynamic testing, and Arm for the embedded toolchain the analyser has to be configured against.

Much of the work sits around the analyser rather than in it: a compiler validated against the ISO language standard, an analyser configured to that compiler’s integer type sizes and target, and the records that show the tool detects what the guideline enforcement plan credits it with. GSAS field application engineers work on that layer directly, which is why the Solid Sands compiler and library qualification tooling sits alongside the Perforce analysers in our portfolio.

GSAS operates 11 physical offices in India, with engineering and support presence in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR, alongside Coimbatore, Vadodara and Visakhapatnam. Teams we support on coding standard programmes work in automotive Tier-1 and OEM software, industrial controls, medical devices, avionics and rail. Engineers in Bengaluru, Pune and Chennai can run a proof of concept on your own codebase, and teams in Hyderabad, Mumbai and Delhi NCR can work through guideline enforcement plan and deviation process design with your quality group.

Talk to a compliance specialist

---

Trademarks: “MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. AUTOSAR is a registered trademark of AUTOSAR GbR. Other product and company names are trademarks of their respective holders. The MISRA guidelines and MISRA Compliance:2020 are available from the MISRA website.

Related compliance pages: ISO 26262 Automotive Safety | IEC 61508 Industrial Safety | DO-178C Aerospace | UNECE R155/R156 Cybersecurity

Related solutions: Automotive Solutions | Testing and Validation