Using MISRA C and C++ for security and reliability. Part I

Taxonomy of the rules
The MISRA rules are classified according to the C or C++ constructs that they restrict.

For example, some of the categories are Environment, Control Flow, Expressions, Declarations, etc. However, I find that most of the rules also fall into a couple of groups according to the errors that they prevent.

The first group of rules consists of those that intend to make the language more portable. For example, the language does not specify the exact size of the built in data types or how conversions between pointer and integer are handled. So, an example of a rule is one that says:

C Rule 6.3/C++ Rule 3-9-2 (advisory):

Typedefs that indicate size and signedness should be used in place of the basic numerical types.

This rule effectively tries to avoid portability problems caused by the implementation defined sizes of the basic types. We will return to this rule in the next section.

Another source of portability problems are undefined behaviors. A program with an undefined behavior might behave logically, or it could abort unexpectedly. For example, using one compiler, a divide by 0 might always return 0. However, another compiler may generate code that will cause hardware to throw an exception in this case. Many of the MISRA C rules are there to forbid behaviors that produce undefined results because a program that depends on undefined behaviors behaving predictably may not run at all if recompiled with another compiler.

Unlike this first group of rules that guard against portability problems, the second group of rules intends to avoid errors due to programmer confusion. While such rules don’t make the code any more portable, they can make the code a lot easier to understand and much less error prone.

Here’s an example:

C Rule 7.1/C++ Rule 2-13-2 (required):

Octal constants (other than zero) and octal escape sequences (other than “\0”) shall not be used.

By definition, every compiler should do octal constants the same way, but as I will explain later, octal constants almost always cause confusion and are rarely useful. A few other rules are geared toward making code safe for the embedded world. These rules are more controversial, but adherence to them can avoid problems that many programmers would rather sweep under the carpet.

Part Two will present examples of rules.
Part Three will be about applying MISRA C and C++

----------------------
If you found this article to be of interest, visit Military/Aerospace Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of military, defense and aerospace. And, to register to our weekly newsletter, click here.