A Brief History of MISRA

The collaborative MISRA project was conceived in the early 1990s, to develop guidelines for the creation of embedded software in road vehicle electronic systems. In November 1994, Development guidelines for vehicle-based software was published.

The collaboration continued, and in April 1998 the first edition of MISRA C was published.

Originally, MISRA C was targeted solely at the automotive industry. However, it was quickly recognised that its applicability was much broader… this was captured by a name-change for the 2^nd edition.

• 1^st Edition   April 1998        Guidelines for the Use of the C Language in Vehicle Based Software
• 2^nd Edition   October 2004  Guidelines for the Use of the C Language in Critical Systems
• 3^rd Edition   March 2013     Guidelines for the Use of the C Language in Critical Systems

Now in its 3^rd Edition, MISRA C has become the de facto standard for embedded C programming in the majority of safety-related industries, where security is paramount, and is also used to improve software quality even where safety or security is not the main consideration.

A Background to MISRA C

The C Language Definition

While very popular, the C language has several drawbacks. In particular, the language definition (an ISO standard) does not completely specify the language and but places some aspects under the control of a compiler-implementation. This is intentional, partly because of the desire to support many pre-existing implementations for widely different target processors.

As a result, there are areas of the language in which:

• The behaviour is undefined – i.e. the Standard imposes no requirements
• The behaviour is unspecified – i.e. the Standard allows for two or more possibilities and imposes no further requirements on which is chosen in any instance
• An implementation is free to choose its own behaviour, provided that this is documented

A program that relies on undefined or unspecified behaviour is not guaranteed to behave in a predictable manner; likewise, a program that relies on implementation-defined behaviour may be difficult to port to a different target.

Language Misuse

While C programs can be laid out in a structured and comprehensible manner, C makes it easy for programmers to write obscure code that is difficult to understand.

The specification of the operators makes it difficult for programming errors to be detected by a compiler. For example, the following two fragments of code are both perfectly legal, so it is impossible for a compiler to know whether one has been mistakenly used in place of the other:

if ( a == b )          /* tests whether a and b are equal                */

if ( a = b )            /* assigns b to a, and then tests whether a is non-zero */

Language Misunderstanding

There are areas of the language that are commonly misunderstood by programmers. For example, C has more operators than some other languages and consequently has a high number of different operator precedence levels, some of which are not intuitive.

The type rules provided by C can also be confusing to programmers who are familiar with strongly-typed languages. For example, operands may be “promoted” to wider types, meaning that the type resulting from an operation is not necessarily the same as that of the operands.

For example:

uint8_t     c = 0x82;
signed int d;

d = c << 1;               // The << operator on a UINT8 returns a SIGNED INT

Run-time error checking

C programs can be compiled into small and efficient machine code, but the trade-off is that there is a very limited degree of run-time checking. C programs generally do not provide run-time checking for common problems such as arithmetic exceptions (e.g. divide by zero), overflow, validity of pointers, or array bound errors.

The C philosophy is that the programmer is responsible for making such checks…

So, What Is MISRA C?

With all of this in mind, the MISRA C Guidelines define a predictable subset of the C language in which the opportunity to make mistakes is either removed or reduced.

As well as defining this subset, these MISRA C Guidelines provide:

• Educational material for those developing C programs
• Reference material for tool developers

The recommendations within these guidelines, when used within a documented software development process, address many of the disadvantages of the C language, irrespective of the purpose of the end-use of the developed code.

By defining a predictable subset of the C language, and offering guidance for developers, MISRA C provides best practice guidelines for the safe- and secure-application of embedded control systems and standalone software.

About the Author

Andrew Banks is the current Chairman of the MISRA C Working Group. Approaching 30 years of experience in high-integrity software design and development, he is a Chartered Fellow of the British Computer Society, and is also active in the standards community.

In early 2018, Andrew joined Liverpool-based software company LDRA (www.ldra.com).

Acknowledgements

This article includes material from MISRA C:2012 Guidelines for the Use of the C Language in Critical Systems (ISBN 978-1-906400-10-1 paperback, ISBN 978-906400-11-8 PDF).

"MISRA" and "MISRA C" and the triangle logo are registered trademarks of HORIBA MIRA Limited, held on behalf of the MISRA Consortium (www.misra.org.uk).