Page 170 - Safety Risk Management for Medical Devices

Software Risk Management 149

assertion for which a static checking tool can prove that it can never fail or
never hold violates this rule. (I.e., it is not possible to satisfy the rule by add-
ing unhelpful “assert(true)” statements.)
6. Rule: Data objects must be declared at the smallest possible level of scope.
7. Rule: 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.
8. Rule: 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 allowed. All macros must expand
into complete syntactic units. The use of conditional compilation directives is
often also dubious, but cannot always be avoided. This means that there
should rarely be justification for more than one or two conditional compila-
tion directives even in large software development efforts, beyond the standard
boilerplate that avoids multiple inclusion of the same header file. Each such
use should be flagged by a tool-based checker and justified in the code.
9. Rule: The use of pointers should be restricted. Specifically, no more than one
level of dereferencing is allowed. Pointer dereference operations may not be
hidden in macro definitions or inside typedef declarations. Function pointers
are not permitted.
10. Rule: 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 any warnings. All code must be
checked daily 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.