If you’re working with safety-critical or high-security software, you’ve probably heard of MISRA C—a set of coding guidelines designed to keep systems robust, reliable, and secure. Originally introduced in 1998, MISRA C has been a go-to standard for industries like aerospace, defense, automotive, medical, and industrial automation, where code quality is non-negotiable. 

Over the years, these guidelines have evolved to address new challenges in embedded and software-intensive systems. The latest updates continue that mission, making it easier for developers to write safe, secure, and maintainable C code. And if you’re using the LDRA tool suite, you’ll be glad to know that support for the latest MISRA C revision became available in the tool suite on the same day the standard was officially released. 

Tackling software vulnerabilities head-on 

Software vulnerabilities—especially memory safety issues—are a major headache for developers and Original Equipment Manufacturers (OEMs) alike. But as Andrew Banks (LDRA technical specialist and chairman of the MISRA C Working Group) points out, many of these vulnerabilities don’t stem from the C language itself. Instead, they often arise from developers cutting corners or bypassing best practices. 

Andrew Banks

By following MISRA C, developers can avoid memory safety pitfalls, improve code clarity, streamline testing, and ensure their software remains maintainable in the long run. In short? These guidelines don’t just make your code safer — they make your life easier. 

What’s in a name?  

On the face of it, MISRA C:2023 was the successor to MISRA C:2012. But things got a little confusing back in 2019, when MISRA C:2012’s third edition (first revision) introduced some significant updates. In hindsight, calling it MISRA C:2019 might have made things clearer. 

So, if you’re assuming that MISRA C:2025 is a massive overhaul just because it has a new year in its name—think again. The change is more about reflecting the MISRA committee’s responsiveness to industry feedback than signalling a groundbreaking shift. 

That said, MISRA C:2023 was a game-changer. It brought in multithreading support, atomic types for safer concurrency, and a more unified reference structure, consolidating previous versions into a single comprehensive edition. 

MISRA C:2025 on the other hand, is more of a fine-tuning update. It introduces enhanced policies and additional guidelines that smooth out compliance while setting the stage for future C standard revision 

Restructuring of front material 

The “front material” of the document consists of introductory sections that appear before the core technical content. These sections help readers understand the scope, intent, and structure of the technical content. 

 Most of the changes here impact section 6 “Introduction to the Guidelines” and even they are mostly concerned with reordering and renumbering. The exception is a new subsection 6.4.4 which deals with disapplied guidelines. 

Changes to the MISRA C Guidelines 

There are 79 changes to the Guidelines which vary in nature as follows: 

• 4 new Guidelines 

• 3 renumbered Guidelines 

• 2 deleted Guidelines 

• 1 disapplied Guideline 

• 69 other modified Guidelines, consisting of 

• 12 normative or technical changes (impacting binding rules, directives, or requirements that must be adhered to for compliance) 

• 57 informative and editorial changes 

• 2 purely editorial changes  

The Guideline changes 

Here’s a quick look at the four new Guidelines and why they were introduced: 

• R.8.18 (Required) “Tentative definitions shall not be made in a header file”
  Tentative definitions occur when a variable is declared without an explicit initializer. If a tentative definition appears in multiple translation units (i.e., different .c files that include the same header), it can lead to linker errors or unintended multiple definitions. 

• R.8.19 (Advisory) “External declarations should not be made in a source file”
  Using external (extern) declarations in a .c file is generally considered bad practice because it can lead to poor maintainability, hidden dependencies, and potential linkage issues. 

• R.11.11 (Advisory) “Pointers shall not be implicitly compared to NULL”
  Implicitly comparing pointers to NULL (i.e., omitting an explicit comparison) can lead to reduced code clarity, potential confusion, and unintended logical errors. Writing explicit comparisons improves readability and reduces misunderstandings. 

• R.19.3 (Required) “A union member shall not be read unless it has been previously set”
  Reading a union member before it has been explicitly assigned a value is undefined behaviour in C. This can lead to unpredictable results, including garbage values, crashes, or unintended program behaviour. 

The remaining Guideline changes are mostly refinements—one Rule was converted into a Directive, two Guidelines were deleted and their content merged into others, and one Guideline was disapplied. 

Revised Examples 

Several examples have been updated due to policy changes. Notably: 

• Directive 4.6 states that “typdefs that indicate size and signedness should be used in place of the basic numerical types” Floating point types (including Complex) have been removed from its scope because they are inherently implementation-defined, and their characteristics extend beyond just size. 

• Some examples previously included #include <stdlib.h> to get to the definition of NULL. They have been updated to #include <stddef.h>, which is universally available across implementations. 

Changes to the appendices  

The appendix updates are mostly similar in nature to those made to the front material. These include minor table updates and the introduction of subsection identifiers to make referencing content easier. One more notable change is the removal of Appendix I (Example deviation record placeholder)  

Revised Reference nomenclature 

In the MISRA Guidelines documents, “References” point to external documents, standards, or sources that the MISRA guidelines cite or rely upon. In MISRA C:2025, C90 implementation defined behaviours have been enumerated differently to both be consistent with the C language standards, and to allow undefined & unspecified behaviours to be annotated more clearly.  

To summarize 

The new MISRA C:2025 document builds on the efficiency of MISRA C:2023, introducing meaningful policy changes, enhancements, and new guidelines to streamline the development of safe and secure code. More importantly, it sets the groundwork for future updates to the C standard, ensuring continued compliance and robustness in safety-critical applications. 

While it may not be a massive overhaul, this update reflects ongoing efforts to make C coding safer, clearer, and more maintainable. Whether you’re deep into compliance work or just aiming to write better code, these refinements are well worth paying attention to. 

More information on the application of MISRA C:2025 and LDRA’s support for it can be found here: 

Blog: MISRA Myths Busted #1 – Is MISRA C *just* an Automotive Standard? 

Blog: MISRA Myths Busted #2 – Is MISRA C *just* a Safety Standard? 

Website: The MISRA Language Guidelines, MISRA C, and MISRA C++ – What they’re for, what’s current and what isn’t. 

Website: Coding standards compliance for embedded systems 

Website: Standards development