Development Testing with Static Analysis

I’ve recently come across an EE Times article written by Coverity stressing the benefits of static analysis and how it can help finding potential issues in the code early.

They mentioned 3 static analysis techniques:

• Dataflow analysis
  This technique can find the defect in the listing below during compile time.
  
  void null_pointer_deref(int x) { char *p; if (x == 0) { p = foo(); } else { p = 0; } if(x != 0) { *p; } else { ... } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  void null_pointer_deref(int x) {     char *p;     if (x == 0) {         p = foo();     } else {         p = 0;     }     if(x != 0) {         *p;     } else {         ...     } }

  
  If value of x passed into the function is not zero, p is assigned a null pointer with p=0. Then, the next conditional check (x!=0) takes a true branch and in the next line p is dereferenced, leading to a null pointer dereference. This type of issue can be detected at compiled time with dataflow analysis.
• Interprocedural analysis
  This technique can find defects across function and method boundaries. See listing below:
  
  void *zero_alloc(size_t size) { void *p = malloc(size);   if (!p) return NULL; memset(p,0,size); return p; } struct S *create_S(int initial_value) { struct S *s = (struct S *) zero_alloc(sizeof(*s)); if (!s) return NULL; s->field = initial_value; return s; } int example_leak(struct S *s, int value) { struct S *tmp = s; if(!tmp) { tmp = create_S(value); } if(!tmp) return -1; ... return 0; }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

  void *zero_alloc(size_t size) {     void *p = malloc(size);     if (!p) return NULL;       memset(p,0,size);     return p; }   struct S *create_S(int initial_value) {     struct S *s = (struct S *) zero_alloc(sizeof(*s));     if (!s) return NULL;     s->field = initial_value;     return s; }   int example_leak(struct S *s, int value) {     struct S *tmp = s;     if(!tmp) {        tmp = create_S(value);     }     if(!tmp) return -1;     ...     return 0; }

  
  There are 3 functions: example_leak, create_S and zero_alloc. Interprocedural analysis  can go through the code and identify the memory leak.  The analysis engine has to trace the execution to understand that memory is allocated in zero_alloc, initialized in create_S and leaked when variable tmp goes out of scope when we return from function example_leak.
• False-path pruning
  This technique tries to ensure that the reported defects are real and to do so it analyzes only the executable paths.  Basic static analysis may find defects on paths that can never be executed because of data dependencies as shown in the listing below.
  
  void null_pointer_deref(int x) { char *p; if (x != 0) { p = foo(); } else { p = 0; } if(x != 0) { *p; } else { ... } }

  1 2 3 4 5 6 7 8 9 10 11 12 13 14

  void null_pointer_deref(int x) {     char *p;     if (x != 0) {         p = foo();     } else {         p = 0;     }     if(x != 0) {         *p;     } else {         ...     } }

  
  This code is slightly modified from the listing used for dataflow analysis. In this case, dataflow analysis would report a null pointer dereference defect (if x != 0). But that would be a false positive because the execution logic will never traverse this path. False-path analysis technique would prune a path that can never be executed (a false path) and good analysis can report up to 50% fewer false positive.

Those static analysis techniques allows code error discovery earlier and can avoid unnecessary late night debugging. Beside dererenced pointers and memory leak, static analysis can also detect other defects such as memory corruptions caused by incorrect integration operations, misused pointers, other resource leaks besides memory, invalid memory accesses, undefined behavior due to uninitialized value usage and many more.

The rest of the EEtime articles deals with Static Analysis with Agile development and how static analysis can be used on different code branches and shared code, but I’m not going to cover those here.

There are different tools available such as Coverity Static Analysis. See video below for a demo.

There was also a session at Android Open 2011 called Static Analysis For Improved Application Performance And Quality presented by Eric Cloninger (Motorola Mobility). This session showed the types of problems that compilers, debuggers, and test suites can’t solve. Items that often only show up in real-world situations for consumers and end-users and introduces the MOTODEV App Validator tool as a solution for developers. I understand that this tool is free but can only be used for Android applications.

There are also many other tools. Some open source C/C++ static analytic tools include:

• Clang compiler (part of LLVM)
• Eclipse with CODAN static code analyser
• cppcheck – Static analysis tool for C/C++ code
• Lint – The original C code static analyser.

Check Wikipedia for a more exhaustive list of commercial and free static analysis tools for different languages.

 

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress