Code Analysis Discussion With LDRA

1 of Enlarge image

Dr. Mike Hennell, founder of LDRA

Static and dynamic code analysis can improve application performance, safety and reliability by identifying problems early in the development cycle if the proper tools and procedures are used from the start. Dr. Mike Hennell, founder of LDRA, spoke with me about the various aspects of these types of tools.

Wong: What is static analysis? What kinds of software errors does it identify?

Hennell: Static analysis is performed on the code itself which is usually but not necessarily in a high- level language. The code is not executed. Static analysis is directed at finding the technical faults in the code. These are the class of faults which could occur in any piece of code regardless of application and are features of the language itself and the understanding and intent of the programmers. An example would be a divide-by-zero fault which could in principle occur in any application. In general, the technique is based on knowledge of the syntax of the language and only limited use of the semantics.

Static analysis can consist of a simple scan of the code in order to discover violations of simple rules such as use of goto statements, or it can consist of a deep analysis of the whole project scanning all possible paths in order to discover whether, e.g. files can be written to after they have been closed.

However, the definition of static analysis is contentious and many formal methods techniques can also be included in this category.

Examples of the techniques performed by static analysis are:

• Programming standards verification – which assesses if the source code confirms to a particular set of programming rules or guidelines.
• Structured programming verification – which determines whether a program is well structured.
• Complexity metric production – which measures a range of complexity metrics such as cyclomatic complexity, knots, essential cyclomatic complexity, essential knots, loop depth, etc.
• Full variable cross referencing – which relates the uses of global and local variables across a project allowing for aliasing (through pointers, references and parameters).
• Unreachable code reporting – which shows that control flow cannot reach the components.
• Static data flow analysis which follows the use of variables through the control flow graph and reports anomalous events, e.g. the computation of a value which is never used.
• Loop analysis – which assess the interrelationships of loops, ensuring that they are properly formed and do not have unnecessary complexity or the ability to loop forever.
• Recursive procedure analysis – which reports the use of various types of recursion and detects whether there is a recurse forever capability or potential to run out of stack space.
• Procedure interface analysis – which analyses the procure interfaces for defects and deficiencies. The interfaces are then projected through the complete project to detect integration faults.
• Pointer analysis – which looks at the use of pointers and the objects to which they point in order to detect anomalous behaviour.
• File usage analysis – which traces the control flow graph for defects in the use of files, .e.g. failure to open before writing, failure to close, multiple opening, multiple closing etc.
• Deadlock detection – which looks for various types of concurrent execution which can cause mutual interference and run-time faults.
• Information flow analysis – which relates the input variables to the output variables.