The new MISRA C:2025 rules are out. But what exactly is new and what has changed?
MISRA C is a set of guidelines developed to improve the safety, security, and reliability of C code in safety-critical systems. Over the years, the MISRA guidelines have become one of the most important standards to follow when developing complex embedded systems which leave no margin for error when it comes to safety, security, and reliability. Especially the automotive, medical and aerospace sectors require software to be compliant with the MISRA guidelines.
The last major update of the rules took place in 2023. The newly released MISRA C:2025 rule set is by no means as big – more of a tweaking of the MISRA C:2023 rules - but it does have a few changes which are worth exploring.
New Guidelines in MISRA C:2025
There are four new rules in MISRA C:2025
Rule 8.18: Tentative definitions shall not be made in a header file
The rule prevents objects being created multiple times in different compilation units in cases where it is not obvious for developers whether a tentative definition is acting as a definition or a declaration.
Let us look at an example. Consider an implementation file containing declarations for the two variables a and b as int i;int j = 0; and including the following header file:
/* the following is a non-compliant tentative definition */
int32_t i;
/* while the following is a compliant external declaration */
extern int32_t j;
Rule 8.19: External declarations should not be made in a source file
The rule is supposed to increase maintainability and modularity by enforcing clear interfaces. In particular, it now considers the case of external variables being declared inside headers but still part of implementations as in:
void uses_externs( void )
{
/* non-compliant external declared in implementation of uses_externs */
extern int32_t i;
}
Rule 11.11: Pointer shall not be implicitly compared to NULL
Extends MISRA’s essential type system to further cases and enforces Boolean expressions instead of pointers where appropriate. This considers casting as well as comparisons inside conditionals, i.e. the following snippets are non-compliant:
int *ptr;
/* non-compliant cast to bool */
(bool) ptr;
/* non-compliant comparison in condition */
if(ptr)
{}
Rule 19.3: A union member shall not be read unless is has been previously set
Reading an inactive union member is resulting in implementation-defined or even undefined behaviour depending on the C Standard used. This of course is inappropriate for safety-critical systems.
For this rule, a non-compliant code snippet would write to one member of a union (thus turning it the active member) and then read from another one, as in:
union
{
int member1;
float member2;
} my_union;
/* following line renders member1 the active member */
my_union.member1 = 5;
/* non-compliant usage of the inactive member2 */
if(my_union.member2)
{}
Other changes compared to MISRA C:2023
There are other changes to some of the MISRA rules. Multiple rules have been clarified, extended with new exceptions or renumbered. Several examples have been extended for additional clarification of the desired behaviour.
Finally, the famous “single point of exit” rule has been recategorized and is now “disapplied”, indicating that compliance is no longer required from a MISRA perspective and no enforcement is expected. However, developers should keep in mind that other regulations such as IEC 61508 and ISO 26262 still encourage comparable means and might enforce the MISRA rule to be applied in certain projects and under certain conditions.
Conclusion
While the changes published with MISRA C:2025 might not seem substantial, they do ensure MISRA stays up to date with the latest developments and keeps supporting the development of safety-critical applications. Following the MISRA guidelines is not only a matter of compliance. It impacts the quality and maintainability of the code, helping you develop future-proof software.
Learn more
If you need to comply with the MISRA guidelines, we can help. Axivion's MISRA checker covers 100% of all automatically testable MISRA rules.
Note: All MISRA coding rules and directives are copyright ©The MISRA Consortium Limited 2025.
