Feature: Software and tools
The gap between functional code and certifiable code is wider than many developers expect
audits scrutinise and where projects often falter, despite clean reports. While not formal MISRA C
terminology, this three-level model reflects how compliance is experienced in real world projects.
Libraries are a major challenge One of the most underestimated drivers of MISRA C cost and complexity is third-party code. In a Bluetooth integration for a Tier 1 supplier, a large externally developed library contained hundreds of thousands of lines of code, leaving little control over its internal implementation. While application code aligned naturally with MISRA C, the library required extensive deviation reporting, isolation strategies and carefully justified documentation of every interaction with non-compliant code.
This is a reality rarely covered in
training: Third-party libraries often account for a disproportionate share of MISRA C compliance effort and cost.
The real costs involved For new developments where MISRA C compliance is built in from the start, we recommend estimating additional cost of approximately 15% to the total development effort. To address issues immediately and avoid end-of-project surprises, we run continuous checks as we develop. Retrofitting compliance to legacy code
is far costlier with 30-35% more effort. You’re re-engineering working code, risking new bugs. Delaying compliance is an expensive mistake. Understanding these costs is only
half the challenge. Avoiding common mistakes is where most teams either lose or save significant time and money.
www.electronicsworld.co.uk March 2026 31
Three mistakes to avoid to reduce costs From multiple MISRA C and automotive projects, common pitfalls I’ve seen occur repeatedly include:
Not taking the process seriously at the start. Create a compliance plan early with stakeholders – categorise rules as mandatory or advisory, outline strategy, and document your approach. Skip this planning phase, and you’ll spend months arguing about which rules truly matter for your specific application. The standard’s flexibility is intentional, so use it wisely, or face prolonged debates.
Running MISRA checks only at the end of a project turns manageable issues into technical debt. Violations accumulate, fixes become disruptive, and teams are forced into
risky late-stage changes. Integrating compliance checks into daily development keeps issues small, visible and far easier and cheaper to correct.
Underestimating memory management. Most violations occur here, directly tying to safety and security risks. Pointer checks, bounds handling and allocation rules aren’t mere bureaucracy, they directly prevent buffer overflows, crashes and security vulnerabilities that can lead to failures in the real world.
Over-compliance: why following every rule isn’t always better Surprisingly, excessive compliance can also harm a project. Making all advisory rules mandatory restricts developers unnecessarily. MISRA C categorises rules deliberately: some are essential for safety, whilst others are contextual good practices. When every advisory rule is treated
as mandatory, developers waste time working around arbitrary constraints instead of solving real problems. This often leads to convoluted code and additional workarounds without improving safety. Experience shows that a small subset of rules consistently carries the greatest safety impact, whilst
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
