Writing Safety Critical Code Checklist

Do not use goto statements, setjmp or longjmp constructs, and do not use direct or indirect recursion.

Simpler control flow translates into stronger capabilities for verification and often results in improved code clarity. The banishment of recursion is perhaps the biggest surprise here. Without recursion, though, we are guaranteed to have an acyclic function call graph, which can be exploited by code analyzers, and can directly help to prove that all executions that should be bounded are in fact bounded. 

Note that this rule does not require that all functions have a single point of return -- although this often also simplifies control flow. There are enough cases, though, where an early error return is the simpler solution.

It must be possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule is considered violated.

The absence of recursion and the presence of loop bounds helps to prevent runaway code. This rule does not, of course, apply to iterations that are meant to be non-terminating (e.g., in a process or task scheduler), but those cases are relatively rare.

A simple way to comply with this rule is to add an explicit upper-bound to all loops that have a variable number of iterations (e.g., code that traverses a linked list). When the upper-bound is exceeded an assertion failure is triggered, and the function containing the failing iteration returns an error. 

The upper-bound serves to prevent infinite looping, so in that sense the absolute value of that bound is less important. Tight bounds are still preferred to prevent that a runaway loop does much damage before the bound is reached, and the error detected. Assertions can be used fruitfully in these cases to claim that the loop bound is never exceeded

This excludes the use of malloc, sbrk, alloca, and all variants, after thread or process initialization.

This rule is common for safety critical software and appears in most coding guidelines. The reason is simple: memory allocators, such as malloc, and garbage collectors often have unpredictable behavior that can significantly impact performance. A notable class of coding errors also stems from mishandling of memory allocation and free routines: forgetting to free memory or continuing to use memory after it was freed, attempting to allocate more memory than physically available, overstepping boundaries on allocated memory, etc. 

Forcing all applications to live within a fixed, pre-allocated, area of memory can eliminate many of these problems and make it easier to verify memory use. Note that the only way to dynamically claim memory in the absence of memory allocation from the heap is to use stack memory. In the absence of recursion (Rule One), an upper-bound on the use of stack memory can derived statically, thus making it possible to prove that an application will always live within its pre-allocated memory means.

A function should not be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration. Typically, this means no more than about N=60 lines of code per function. 

N can be set to any reasonable value in the range 50..100 lines.

Each function should be a logical unit in the code that is understandable and verifiable as a unit. It is much harder to understand a logical unit that spans multiple screens on a computer display or multiple pages when printed. Excessively long functions are often a sign of poorly structured code.

Assertions are used to check for anomalous conditions that should never happen in an execution. Assertions must be side-effect free and are best defined as Boolean tests. When an assertion fails, an explicit recovery action should be taken, e.g., by returning an error condition to the caller of the function that executes the failing assertion. Assertions for which a static checking tool can prove that it can never fail or never hold should be removed and replaced with comments. (This means that it is not possible to satisfy the rule by adding unhelpful assert(true) statements throughout the code.)

For safety critical code, typical values for N and M are N=2 and M=20. For less critical applications, the value of M could be increased but to be meaningful it should always be smaller than the maximum function length

Statistics for industrial coding efforts indicate that unit tests often find at least one defect per 10 to 100 lines of code written. The odds of intercepting defects increase with assertion density. Use of assertions is often also recommended as part of a strong defensive coding strategy. Assertions can be used to verify pre- and post-conditions of functions, parameter values, return values of functions, and loop-invariants. Because assertions are side-effect free, they can be selectively disabled after testing in performance-critical code.

Assertions should never be disabled. (E.g., they do not just serve to improve the effectiveness of software testing -- they also serve an important role at runtime to catch misbehaving code at the earliest possible moment.)

This rule supports a basic principle of data-hiding. Clearly if an object is not in scope, its value cannot be referenced or corrupted. Similarly, if an erroneous value of an object has to be diagnosed, the fewer the number of statements where the value could have been assigned; the easier it is to diagnose the problem. The rule discourages the re-use of variables for multiple, incompatible purposes, which can complicate fault diagnosis.

The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.

This is possibly the most frequently violated rule, and therefore somewhat more suspect as a general principle. In the strictest interpretation, this rule means that even the return value of printf statements and file close statements must be checked. 

A case can be made, though, that if the response to an error would rightfully be no different than the response to success, there is no point in checking a return value. This is often the case with calls to printf and close. In cases like these, it can be acceptable to explicitly cast the function return value to (void) -- thereby indicating that the programmer explicitly and not accidentally decides to ignore a return value. The rule is then only violated if the cast is missing. 

In more dubious cases, a comment should be present to explain why a return value is irrelevant.

In most cases, though, the return value of a function should not be ignored, especially if error return values must be propagated up the function call chain. Standard libraries famously violate this rule with potentially grave consequences.

The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not permitted. 

All macros must expand into complete syntactic units. 

The use of conditional compilation directives should be restricted to the prevention of duplicate file inclusion in header files.

The C preprocessor is a powerful obfuscation tool that can destroy code clarity and befuddle many text based checkers. The effect of constructs in unrestricted preprocessor code can be extremely hard to decipher, even with a formal language definition in hand. In a new implementation of the C preprocessor, developers often have to resort to using earlier implementations as the referee for interpreting complex defining language in the C standard. The rationale for the caution against conditional compilation is equally important. Note that with just ten conditional compilation directives, there could be up to 2^10 (i.e., 1024) possible versions of the code, each of which would have to be tested -- causing a significant increase in the required test effort.

Limit the use of pointers. Use no more than N levels of dereferencing (star operators) per expression. A strict value for N=1, but in some cases using N=2 can be justified.

Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. The use of function pointers should be restricted to simple cases.

Pointers are easily misused, even by experienced programmers. They can make it hard to follow or analyze the flow of data in a program, especially by tool-based static analyzers. Function pointers, similarly, can seriously restrict the types of checks that can be performed by static analyzers and should only be used if there is a strong justification for their use, and ideally alternate means are provided to assist tool-based checkers determine flow of control and function call hierarchies. For instance, if function pointers are used, it can become impossible for a tool to prove absence of recursion, so alternate guarantees would have to be provided to make up for this loss in analytical capabilities.

All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler's most pedantic setting. All code must compile with these setting without warnings. All code must be checked on each build with at least one, but preferably more than one, state-of-the-art static source code analyzer and should pass the analyses with zero warnings.

There are several very effective static source code analyzers on the market today, and quite a few freeware tools as well. There is no excuse for any serious software development effort not to make use of this technology. It should be considered routine practice, especially for critical software development. The rule of zero warnings applies even in cases where the compiler or the static analyzer gives an erroneous warning: if the compiler or the static analyzer gets confused, the code causing the confusion should be rewritten so that it becomes more trivially valid. Many have been caught in the assumption that a warning was likely invalid, only to realize much later that the report was in fact valid for less obvious reasons. 

Static analyzers originally had a bad reputation due to the limited capabilities of early versions (e.g., the early Unix tool lint). The early tools produced mostly invalid messages, but this is not the case for the current generation of commercial tools. The best static analyzers today are fast, and they produce selective and accurate messages.

For an overview of static source code analyzers for C, see here. 

Recommended tools include codesonar, coverity, klocwork, and uno (roughly in that order).