For C programmers working on safety-critical applications, following restrictions and guidelines to ensure safe-coding practices can be painful. Features of the language designed to make your work easier, more efficient, or provide work-arounds for obstacles are often just the features that the guidelines disallow. However, whether for avionics or in the midst of battle, a problem with the software is the last thing needed. The risks prohibit taking chances.
Because of this, adherence to appropriate coding rules is one of the key demands of DO-178B/C. Although DO- 178 does not prescribe adoption of MISRA C, it has become the de facto programming standard for all safety-critical software. The newest version of MISRA C offers new hope for programmers by permitting more flexible use of the language while retaining the MISRA reputation as the safest C guideline available.
MISRA C is a software development language subset that was originally released in 1998 (MISRA C:1998) to target C90. It was superseded in 2004 (MISRA-C:2004) to include a host of extensions and improvements to the original.
While MISRA C is actually a language subset, not a coding standard, it provides a sound basis for coding best practices. Over the years, MISRA C has gained widespread acceptance in safety-, life-, and mission-critical applications including the aerospace and defense industries. It is widely referred to as the MISRA standard.
The new MISRA C aims to make development as predictable as possible, across projects or pieces of code, without errors of interpretation. Repeatability and predictability are key drivers. Even a dispersed development team — such as a prime contractor with many subcontractors — that follows the MISRA guidelines can be confident that all of the code will be consistent across the project. Following the new guidelines, whether classified as rules or directives, helps programmers mitigate software-related risks for safety-critical applications. Ultimately, it allows them to spend more time coding and less time on compliance efforts.
In MISRA C:2012, guidelines have been made more precise so that the standard will not prevent reasonable uses or behaviors that have no undesirable consequences. This will be good news for developers who may have been frustrated in the past by rules that were more restrictive than was necessary for compliance with the DO-178B/C requirements. Instead of MISRA C:2004’s use of the term “rule,” MISRA C:2012 subdivides “guidelines” into “rules” and “directives” where a directive is a guideline for which it is not possible to provide the full description necessary to perform a check for compliance.
The new MISRA standard further defines rules as applying to a “system” or “single translation unit” analysis. And all guidelines now include detailed rationale, which should help developers understand the need for each of them, rather than leaving them to speculate on the rule’s intent.
The updated version also tells developers if a rule is “decidable” — those against which an analysis tool can always determine compliance or non-compliance — versus “undecidable,” where a person must make an assessment, generally due to pointer or data values affecting control flow (Figure 1). Undecidable rules can result in false-positive or false-negative test results simply because the tool has inadequate information available to it during analysis. This improvement in rules definition significantly reduces manual code-review requirements, and lets developers know ahead of time if another method of testing should be used.
MISRA C:2012 Offers a Reasoned Approach
Let us look at some specific examples of programming approaches that are now addressed with the more user-friendly MISRA C:2012.
Freeing Memory (a.k.a., Being Too Clever For Your Own Good)
In some instances, developers have freed memory that is automatically allocated to variables for use elsewhere. This is legitimate C syntax, but is dangerous. The new MISRA rule prevents developers from being too clever for their own good. In this case, the rule states that a block of memory shall only be freed if it was allocated by means of a standard library function.
void fn ( void )
free ( &a ); /* Non-compliant - a does
not point to allocated storage */
MISRA C:2012 defines guidelines as “Required,” “Advisory” or as a new “Mandatory” category, and this memory rule, for instance, is an example of a Mandatory rule that must never be broken (Figure 2). Required and Advisory guidelines can be broken with varying degrees of justification required, so that an “Advisory” rule might be at a programmer’s discretion, while “Required” might require the approval of a manager.
Rationale Behind The Guidelines
The previous versions of MISRA dictated what should be done, offering no rationale to explain the rule’s intention. This new version enhances the concept of “rationale,” providing descriptions that explain why each guideline is a good idea.
For instance, it is now a requirement that typedefs that indicate size and signedness should be used in place of the basic numerical types. For example, on a 32-bit C90 implementation, the following definitions might be suitable:
typedef signed char int8_t;
typedef signed short int16_t;
typedef signed int int32_t;
typedef signed long int64_t;
From the perspective of portability, the rationale debunks the possible false perception that adherence to this guideline guarantees portability because the size of the int type may determine whether or not an expression is subject to integral promotion. For example, an expression with type int16_t will not be promoted if int is implemented using 16 bits, but will be promoted if int is implemented using 32 bits. In other words, the rationale helps guide the developer around a common pitfall.
Not All Goto Statements Are Evil!
All too often, goto statements are used to patch up fuzzy thinking or an ill-defined algorithm. Indeed, there are situations where the use of the goto statement is justified. For example, if there is an emergency situation in a guidance algorithm, it is better to take a direct route via a goto. There’s not time to set a flag and check its status later in the loop. Because of this, the “goto statement should not be used” rule is now advisory rather than required, and an additional two rules narrow down the circumstances under which it is acceptable:
- The goto statement shall jump to a label declared later in the same function.
- Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.
MISRA C:2012 And Beyond
Although MISRA C:2012 provides an ideal basis for a language subset for any mil/aero safety-critical application, DO-178B/C does not dictate exactly what coding rules should be applied. With the right tools to help, development teams gain the flexibility to fine-tune the rule set to the requirements of a particular project by extending it with additional in-house rules or, with appropriate justification, by disabling selected MISRA rules (Figure 3). For example, Lockheed-Martin took exactly this approach for the Joint Strike Fighter. They developed the JSF++ AV rules set based on the MISRA C++:2008 standard.
MISRA Helps Meet Coding Best Practices
MISRA, in all its flavors, was developed to help software development teams create software applications of the highest quality. MISRA-checked code has fewer defects and it is more maintainable, readable, consistent and verifiable. Essentially, MISRA is about applying best practices in coding, a principle underlined by the references to appropriate coding rules in DO-178B/C. Under standing and meeting the requirements of MISRA C:2012 can help you meet high software-quality assurance requirements while allowing you to make better decisions about features of the programming language.
Test tools that support MISRA compliance should allow you to easily choose between versions of the standard (C, C++, Java) and appropriate subset (MISRA C:2004 for legacy and MISRA C:2012 for new projects), and should allow you to choose full compliance or a user-defined subset of rules that meet in-house templates or requirements.
This article was written by Chris Tapp and Mark Pitchford, Field Applications Engineers, LDRA (Wirral, UK). For more information, Click Here .