A Survey of Changes in the Latest Revision
MISRA C from the Motor Industry Software Reliability Association has been around since 1998 and enjoys wide adoption across embedded software development for safety critical systems. The guidelines limit the use of the C language to enforce determinism, prevent run-time faults, and provide consistency across target platforms. MISRA C: 2025 updates include clarifications and the addition of a few new guidelines.
MISRA C is too restrictive for many modern, networked devices that require dynamic memory allocation. It does remain a widely recognized standard in low-level safety critical systems. Isolating low-level control in a MISRA compliant implementation on a microcontroller is a key mechanism for risk mitigation in safety critical software.
New Directives
The 2025 edition includes four new guidelines. None of the guidelines prevent use of C language features, nor do any of the directives negatively impact software performance. There isn’t a good reason to avoid adoption in new software development regardless of categorization as Required or Advisory.
Rule 8.18: Tentative definitions shall not be made in a header file
Summary: Don’t put variable declarations in header files.
Tentative declarations in a header will cause multiple declarations if the header is used in multiple source files. Move the variable definition to a .c source file and define the variable as an extern in the header.
Rule 8.19: External declarations should not be made in a source file
Summary: Only put extern’s in header files.
Putting an extern in .c source file breaks the limited encapsulation provided by the C language. Move the extern to a header file associated with the .c source.
Rule 11.11: Pointer shall not be implicitly compared to NULL
Summary: Pointers contain addresses. Only compare pointers to addresses (ex: NULL)
Modern C programming should strive for strong typing. A pointer contains an address. NULL is an address. While a NULL addresses evaluates as 0 or false, maintain strong typing by comparing addresses.
Rule 19.3: A union member shall not be read unless is has been previously set
Summary: Don’t use unions to circumvent type checking or perform implicit conversions.
While a union supports converting raw memory between types, don’t do it. Behavior is platform specific, impacted by byte packing, dependent on endian format, and difficult to document. A common application of this technique is the manipulation of bits in IEEE floating point formats. Use a byte array that is endian aware and rebuild values from the specific bytes.
Additional Changes
Appendix A.2 lists the guidelines withdrawn for 2025. The withdrawn guidelines merge with other rules. Appendix J contains a complete list of modifications in a change log. The majority of the changes are related to correct for various C language specifications. The biggest benefit of the changes in the new edition is the inclusion of improved examples.
Reconciliation with BARR:C 2018
The 2018 edition of the Embedded C Coding Standard by Michael Barr presents another popular set of guidelines, colloquially known as BARR:C 2018. While MISRA focuses on using safety, BARR focuses on preventing defects. BARR goes farther than MISRA through the definition of style in addition to feature use and aligns cleanly with MISRA C:2012.
BARR:C doesn’t call out the four new MISCRA C directives for 2025. As expected, the new directives do not result in a conflict.
Adoption
Static analysis tools and linters will likely incorporate the new guidelines in new revisions. Compiling with increased warnings may also trip on these rules depending on the toolset. In the absence of automated detection, catch the new guidelines via code inspection or review of pull requests.
A mature organization would throw a code smell flag on 8.18 and 8.19 due to potential coupling. Catching 11.1 will require educating developers and simple modifications to legacy code. Rule 19.3 violations should stand out in code reviews due to the associated complexity in union manipulation.
The 2025 revision of MISRA C reflects the maturity of the specification through the limited scope of the modifications. It retains its focus of safety and leaves style to the coding standards.
