Discover TÜV-certified GoogleTest with Agentic AI for C/C++ testing!
Get the Details »
Jump to Section
Parasoft Blog
MISRA has released the first technical corrigenda for MISRA C++:2023. TC1:2026 clarifies rule interpretation, adds new exceptions, and adjusts analysis scope across several guidelines. Read on for the details and learn how C/C++test fully supports these updates.
Jump to Section
At first glance, MISRA C++:2023 TC1:2026 might sound like routine editorial maintenance. There are certainly corrections to wording and examples. But embedded C++ development teams should pay closer attention.
Several updates affect how existing guidelines should be interpreted and applied, including new exceptions, changes to analysis scope, clarification of compliant and noncompliant behavior, and better accommodation of modern C++ programming practices.
That distinction matters when MISRA compliance is enforced through static analysis.
The rule numbers may not have changed, but in some cases how those rules should be enforced has.
An analyzer that hasn’t incorporated the corrigenda could flag code that TC1 now explicitly permits or fail to account for behavior that the updated guidance has clarified. For teams relying on automated analysis as part of a safety- or security-critical development process, staying aligned with the latest interpretation of the guidelines is therefore an important part of maintaining MISRA compliance.
Coding standards inevitably evolve as they are applied to real software. Ambiguities emerge, examples reveal edge cases, and legitimate programming patterns sometimes need additional clarification.
A technical corrigenda provides a way to address those issues without replacing the underlying standard. TC1 does exactly that for MISRA C++:2023, providing the editorial instructions for updating the guidelines to MISRA C++:2023 (TC1:2026).
Some changes are relatively minor, but others have direct implications for static analysis. A construct previously treated as a violation may now fall under a defined exception, while other changes refine what an analyzer needs to understand about program behavior to determine compliance correctly.
There are also cases where the required analysis scope itself has changed. Together, these updates reinforce an important point: meaningful MISRA support is not simply a matter of providing a checker for every rule. The checker must implement the current intent and semantics of the guideline.
Several TC1 updates address programming constructs developers routinely encounter in modern C++ code. One of the simplest examples appears in Rule 0.0.2, where TC1 introduces an exception permitting a controlling expression resulting from expansion of the assert macro. The corrigenda specifically provides assert(false && "Unexpected case") as an example that’s compliant under the new exception.
#include <cassert>
void handleUnexpectedCase()
{
assert(false && "Unexpected case"); // Compliant by TC1 exception
}
Rule 0.1.1 receives considerably broader clarification. Its headline is updated to state that "A write to a local object should be necessary."
TC1 further defines what constitutes a necessary write based on occurrences along feasible execution paths. The update also recognizes [[maybe_unused]] as an expression of developer intent and clarifies treatment of composite types, containers, loops, and functions. These distinctions are important for avoiding findings where the analyzer has technically identified a write but has not correctly understood how that value or object is used.
TC1 also better accommodates established C++ design techniques. Rule 6.4.2, for example, gains an exception for the Curiously Recurring Template Pattern (CRTP). The corrigenda explicitly notes that the previous rule unreasonably prohibited use of the pattern and now permits name concealment under defined CRTP conditions.
A simplified CRTP pattern looks like this:
template <typename Derived>
class Base
{
public:
void interface()
{
static_cast(this)->implementation();
}
};
class Device : public Base
{
public:
void implementation()
{
// Device-specific behavior
}
};
This example illustrates the type of CRTP pattern addressed by the new exception. It does not mean that every use of CRTP is automatically MISRA compliant. Rather, TC1 corrects a situation where the original wording could prohibit an established C++ technique even when used under the conditions now defined by the exception.
Rule 6.2.3 is similarly updated to allow safe, common patterns involving explicit template specializations and header usage. Together, these changes illustrate something important about MISRA C++: safety-critical C++ does not mean avoiding modern C++ constructs. It means using them in ways that are sufficiently understood, constrained, and analyzable to support dependable software.
Other TC1 changes go deeper into the semantics an analyzer must understand. Numeric conversions and comparisons are a good example.
u8 == u8, while recognizing that comparing values of the same type is safe. It also corrects examples that previously included instances of integral promotion. is considered safe.The treatment of moved-from objects is another significant area. TC1 substantially revises Rule 28.6.3 to clarify when a variable has potentially moved-from state, including operations involving std::move, std::forward, std::move_if_noexcept, and equivalent casts. At the same time, the updated guidance recognizes the defined moved-from behavior of std::unique_ptr, std::shared_ptr, and std::weak_ptr.
This is exactly where sophisticated static analysis matters. Simply recognizing the presence of std::move isn’t enough. The analyzer must understand:
The objective is not to produce more findings—it’s to identify the findings that actually matter according to the guideline.
TC1 also demonstrates why MISRA compliance analysis sometimes needs visibility beyond an individual source file.
Rule 0.2.3 changes its required analysis scope from Single Translation Unit to System and expands its treatment of limited-visibility types, including private members, type aliases, templates, lambda closure types, enumerations, and anonymous unions.
An analyzer limited to one translation unit may, therefore, lack the information needed to make the correct determination for this rule.
Interestingly, TC1 doesn’t simply expand analysis scope everywhere. Rule 21.6.4 moves in the opposite direction, changing its scope from System to Single Translation Unit while clarifying requirements involving corresponding sized and unsized global operator delete functions.
These changes reinforce why a MISRA tool cannot be evaluated only by asking whether it "supports Rule X." A more meaningful question is whether the tool performs the type of analysis that Rule X actually requires. Correct rule semantics, language awareness, data and control flow, and appropriate analysis scope all contribute to whether a reported result accurately represents the MISRA guidance.
For organizations already using MISRA C++:2023, TC1 raises a straightforward question: Does your static analysis tool merely claim MISRA C++:2023 coverage, or does its analysis reflect the latest interpretation of the guidelines?
That difference can have practical consequences. When MISRA introduces a new exception, the analyzer should recognize it. When TC1 clarifies previously ambiguous behavior, the checker should apply that clarification.
When a rule’s analysis scope changes, the underlying analysis should change accordingly. Otherwise, development teams may encounter unnecessary findings, missed violations, additional deviation work, or manual review to compensate for outdated analysis behavior.
This is especially important in safety-critical development, where static analysis results frequently contribute to a larger body of compliance evidence. Teams need confidence that a reported violation represents the current guideline, not an interpretation that has subsequently been corrected or clarified.
Parasoft C/C++test fully supports the applicable changes introduced by MISRA C++:2023 TC1:2026. That support goes beyond updating rule descriptions or documentation. C/C++test implements the updated rule semantics, exceptions, analysis requirements, and compliant and noncompliant cases defined by the corrigenda.
For development teams, this removes the burden of manually reviewing the corrigenda and determining how each change should affect existing static analysis. Developers can continue applying MISRA analysis within their normal IDE and CI/CD workflows while working against the latest guidance. This reduces unnecessary investigation of findings based on superseded interpretations while ensuring newly clarified cases are handled correctly.
C/C++test also puts MISRA analysis into the broader verification and compliance workflow. Teams can identify coding-standard violations earlier, remediate them as part of development and CI, and produce the reporting and evidence needed to demonstrate compliance. The objective isn’t simply to run a MISRA checker—it’s to make MISRA compliance a repeatable part of software development.
MISRA C++:2023 TC1 doesn’t replace MISRA C++:2023. It makes the guidance more precise based on issues identified since the guidelines were published. For organizations developing critical embedded software, those refinements matter because precision in the standard needs to translate into precision in the analysis used to enforce it.
A static analysis tool therefore needs to understand more than which MISRA rule applies. It needs to reflect the rule’s latest interpretation, exceptions, required analysis scope, and underlying C++ semantics.
With complete support for MISRA C++:2023 TC1, C/C++test helps development teams keep their MISRA analysis current while continuing to take advantage of modern C++ in safety- and security-critical software.
See how C/C++test can help your team keep its MISRA analysis current.
"MISRA", "MISRA C" and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
