MISRA-C update to land later in March

The Motor Industry Software Reliability Association (MISRA) is nearing publication of the latest version of its coding standard intended to make C safer for use in critical embedded systems.

Although originally conceived by engineers from two UK-based automakers, the MISRA C standard has become widely adopted across industries, including those in military, aerospace and nuclear energy. Research from 2011 by market analyst VDC Research found that MISRA C was the most commonly used coding standard for C employed on embedded projects – second place to inhouse rules.

Paul Burden, technical consultant at Programming Research, said: “What I would say is that if you look at most inhouse coding standards, generally speaking, they tend to pick up MISRA C and modify it. I would say that MISRA C today is largely dominant even though it isn’t the biggest bar on the VDC graph.”

The first revision of the standard took place in the early 2000s, resulting in MISRA-C:2004. “The 2004 update was a technical corrigendum,” said Chris Hills, MISRA-C team member and CTO of tools vendor Phaedrus Systems. The forthcoming update follows a complete overhaul of the standard by a close-knit team of around ten engineers.

“We normally have four two-day meetings a year and have an 95 per cent attendance rate,” said Hills. “When you start to have larger teams on standards work, the attendance rate drops and you get fewer qualified people who can commit to the amount of time needed.”

C99 opportunity

Mark Pitchford, field applications engineer at code-analysis tool vendor LDRA, said: “The driving force was the C99 standard. But the process used the feedback from MISRA C:2004 to address peoples’ concerns and dislikes.”

Burden added: “Most embedded compilers support at least a subset of C99 but not the whole gamut. However, some features are now in widespread use, such as Boolean types and inline functions. Those are the really useful things in C99.”

An important aspect of the 2012 revision, which is due to be published on the 18 March, is the introduction of the concept of decidability. This helps mark rules that can be checked automatically by a static-analysis tool versus those that identify good practice but which do not have clear-cut distinctions and are difficult or impossible to verify without human involvement.

Undecidable rules, on the other hand, rely on interpretation. For example, one rule demands that no code be put into comments – largely to prevent developers from commenting out segments of code to disable it. However, it is very difficult for a tool to determine whether a comment contains potentially executable code.

“This work has exposed the limitations of coding rules, which are often swept under the carpet when devising coding standards,” said Burden. “So the whole concept of compliance has been exposed as a debatable area. If you are claiming compliance the best you can do is say: ‘I am testing compliance with these tools’. It’s a best-effort process. It’s not black and white.”

Cert C contrasts

Burden compared MISRA C to the other widely used standard, developed for security-focused applications, Cert C. “One of the key contrasts between the two, apart from Cert C being three times the size, its ratio of decidability is far, far lower than MISRA C. Although it contains very good advice, it’s very difficult to enforce,” said Burden. “One of the reasons why MISRA C is being used is because it fits in very closely with the use of tool-based enforcement. There is a significant overlap with MISRA but there are also slight contradictions between Cert C and MISRA rules. Something to be investigated is to whether you can write code that is both safe and secure. It’s an open question right now.”

Pitchford added: “This narrowing and focusing also changes in terms of the English so that’s now much more descriptive. It became an educational document and not just do as you’re told.

“Although MISRA C has been used widely across the safety-critical sectors, it did tend to be something that people had to us because they were being certified. But the change in emphasis to ‘use this rule because it’s a good idea’ opens it out to people who just want software to work.”

System and code diversity

A number of changes reflect the growing diversity of systems being built in the embedded space. Some of the rules are considered mandatory by the new standard for the first time.

Burden said: “There are a few rules that we consider to be so common sense and uncontroversial that there can be no sensible reason to deviate from them.”

Most other situations are more complex. “When you can implement critical systems on anything from an 8bit [Microchip Technology] PIC to a 64bit processor, it’s hard to find a rule that’s universal,” said Hills. “You can’t have 100 per cent MISRA-C compliance without deviation.”

Burden: “We’ve inserted quite a lot in our tool to manage the whole business of deviations. We see that as one of the big problem areas of coding standard compliance. Originally [in MISRA C] we banned C unions. The trouble is that if you are doing communications systems, you normally need to use unions to get things in and out of the packet stream. For the most part, you should not use unions but if you deviate from that rule in one or two functions, that’s fine.”

A further change to the standard is that rules for automatically generated have now been incorporated into the main standard. Formerly, these were in a separate document. An example of the difference in rules is, Pitchford explained: “If you have a switch statement, a default is required for manually written code. But a default is required to be absent from autocode.”