Highlights:

• Based on MISRA^® - "Guidelines for the Use of the C Language in Vehicle Based Software"
• Selectable restrictions to ISO/IEC 9899:1990 standard C programming language
• TASKING is the only vendor to include these unique code checking facilities in standard C compiler tools
• Supported on many TASKING compiler tools, including C166, ST10, TriCore, M16C, XA, and 8051
• Well suited for safety-related or mission-critical applications, or where general quality and robustness of code are important

Is the C language appropriate for embedded applications with high safety standards?

C Today

The programming language 'C' is today's de facto standard for high level language programming of embedded systems. Unfortunately, drawbacks in consistency and intrinsic quality make C somewhat unsuitable for programming mission-critical applications, especially those in which user safety is an issue. Today's popularity of C is due to a number of factors:

• The increasing complexity of applications coupled with increasing time to market pressures
• Good support for high-speed, low-level, input/output operations
• Availability of optimizing C cross-compilers
• Support of C by third party code generation tools

C has become popular for embedded development because it offers significant productivity improvements with the opportunity for code re-use, improved code maintenance, and improvements over the life of the application. However using a high level language, even one with a defined standard, does not guarantee problem free code. C can be written in a structured manner that reduces the chance of producing errors. But C can also be written in a very condensed manner, which is hard to comprehend and where the chance of introducing errors is dramatically increased. Quite often, a small typing error can lead to valid C syntax: consider the operators &&, &, ||, |, +=, and ==.

Not every programmer is fully aware of the effects of all the possible constructs in the C language. For instance, the lack of type checking and the application of implicit casts tend to cause confusion and hence errors. A number of the features in C have not been well defined or are defined differently from what a programmer expects.

One of the main reasons that C compilers do a great job of generating small code, is that the C language is generally limited at providing runtime checking. This means that arithmetic exceptions such as divide by zero, overflow, validity of addresses or pointers, or array bound errors will cause a system to crash.

Writing safer, more consistent C

If a safety related application needs to be programmed in a high level language, and C is the language of choice, then there are ways to avoid the drawbacks of C. The Motor Industry Software Reliability Association (MISRA) is a consortium of companies that developed the guidelines on which TASKING's MISRA C code checking is based. This effort was in response to the UK Safety Critical Systems Research Program, and the result is 127 programming rules applicable when developing safety-related applications in C.

A subset of the MISRA C guidelines:

• In the group 'Comments,' nested comments are prohibited and it is advised not to comment out sections of code.

• In the Group 'Identifiers,' a limit is defined of max 31-character significance and the use of identical identifiers is discouraged.

• In the group 'Types,' the basic types char, int, short, long, float and double should be replaced with typedefs indicating the specific length (e.g. SI_16 is a 16 bit signed integer) and the type char shall always be declared as unsigned char or signed char.

• By definition, ANSI C compilers interpret decimal Integer constants with leading zeros as Octal. To prevent mixing up Octal and Integer constants, the use of octal constants is prohibited.

• In the group 'Conversions,' the use of implicit type conversions is prohibited. Also the use of redundant explicit casts is not be used.

• In the group 'Expressions,' a rule describes that the value of an expression should be the same under any permissible order of evaluation and floating point variables are not to be tested for exact equality or inequality.

• In the group 'Control Flow,' the use of goto, break and continue is prohibited. Also a number of constraints on the use of the if, else, switch and case constructs are defined.

• The group 'Functions' defines a large number of required rules on the declaration and use of functions.

• The group 'Pointers and Arrays' prohibits the use of non-constant pointers to functions and advises not to use pointer arithmetic at all.

• The group 'Structures and Unions' requires that all structure/union members are named and referred to by name only.

For a complete reference, read the 'Guidelines for the use of the C language in vehicle based software' by MISRA.

Since the introduction of the Infineon Tricore™ tool chain, TASKING has been the only commercial tools company to offer facilities that allow enforcing of compliance with standards of 'best practice' programming throughout the complete tool chain. TASKING tools allow for adherence to all or a subset of the MISRA guidelines. This way companies can define a subset of the MISRA C rules as their own programming practices. Today, MISRA C code checking is broadly adopted and available in many TASKING tool chains, including Infineon TriCore and C166, STMicroelectronics ST10, Mitsubishi M16C, Philips XA, and 8051 (over two dozen manufacturers supported).

During compilation of the code, violations of the selected MISRA C rules result in error messages, which prevent further processing of the code. To ensure compliance with the MISRA C rules throughout the entire project, the Linker/Locator is able to generate a 'MISRA C Report'. This report lists the different modules in the project with the respective MISRA C configurations that were used to compile them. Filed under our customer's Quality Assurance system, this report can provide proof that 'best practice' programming has been applied in a particular project. So, under the guidance of MISRA C code checking in the TASKING tool chain, programmers can now write code that contains less error-prone C-constructs, which will lead to more robust and safer embedded systems.

MISRA^TM is a registered trademark of the Motor Industry Research Association, held on behalf of the Motor Industry Software Reliability Association.