Helping CodeSonar Out

• Complex Properties of Variables
• Functions That Don't Return
• Analysis 'Assertions'

Complex Properties of Variables

In the following program, CodeSonar cannot infer that procedure foo will always initialize buf[0] because it can't infer that x*x is greater than zero for all x.

#include <stdlib.h>

void foo( char *p, int x)
{
    if( x*x >= 0 )
        *p = 'c';
}

int main(int argc, char *argv[]){
    char buf[10];
    foo(buf, rand() - 500);
    return buf[0]; 
}

Consequently, it will issue an Uninitialized Variable warning at line return buf[0].

What you can do

There are several methods we can use to indicate to CodeSonar that foo always sets *p.

Modify foo.

We can add additional code to foo as shown:

void foo( char *p, int x)
{
#ifdef __CODESONAR__ 
*p = 'c'; 
#endif
    if( x*x >= 0 )
        *p = 'c';
}

Symbol __CODESONAR__ is defined in CodeSonar. Therefore, the CodeSonar build and analysis will now involve a function foo that initializes *p without obfuscation, while normal software builds will use foo that has the same behavior as before.

Implement csonar_replace_foo somewhere in your project.

If we don't want to alter the implementation of foo at all, we can put a function csonar_replace_foo anywhere in your project, and CodeSonar will replace all calls to foo with calls to csonar_replace_foo. (For more on this technique, see section Extending and Customizing CodeSonar.) This replacement function should have the same side-effects as the original foo without the factors that confused CodeSonar. For example:

void csonar_replace_foo( char *p, int x)
{
    *p = 'c'; 
}

Note that in this example csonar_replace_foo does not call foo, unlike many of the other csonar_replace_procedure examples in the Extending and Customizing CodeSonar section. However, it would be perfectly fine to add such a call.

Implement csonar_replace_foo elsewhere.

We may not want to modify our software project at all. In this case, we implement csonar_replace_foo as shown above, but in a separate file instead of in our project. We then build and analyze a CodeSonar project that contains both our software project and this separate file.

For more information and examples of these and other available approaches, see Manipulating the Input to the Build and Analysis

Functions That Don't Return

CodeSonar is not always capable of determining that a function does not return. This may arise because of infinite loops or infinite recursions that are too complex for CodeSonar to identify, or because some procedure is used that has similar semantics to exit but that CodeSonar does not know to interpret as such.

For example, suppose we have a function my_exit with the same behavior as exit. (Note that implementing my_exit as a wrapper for exit will not fool CodeSonar, but some lower-level implementations may do so.) CodeSonar will issue a Null Pointer Dereference warning for this program, even though execution can never reach the line where the dereference occurs:

void bar( char *p, int x)
{
    if (p == NULL)
        my_exit(x);
    p[0] = x;
}

int main(int argc, char *argv[]){
    char buf[10];
    bar(buf, 500);
    return 0; 
}

This null dereference warning is a false positive. The easiest option in this situation is to implement csonar_replace_my_exit. (For more on this technique, see section Extending and Customizing CodeSonar.)

void csonar_replace_my_exit(int i){
    my_exit(i);
    exit(i);
}

More generally, if CodeSonar cannot infer that function baz does not return, implement csonar_replace_baz:

void csonar_replace_baz(param_list){
    baz(params);
    exit(0);
}

Analysis 'Assertions'

assert() statements can cause problems for the CodeSonar analysis if the particular implementation of assert() is such that that CodeSonar cannot determine that execution ends when the statement condition fails. For more information, see CodeSonar and assert().

To inform the analysis of conditions that must hold, use statements of the form:

if (cond) abort();

Note that the abort() prototype must be in scope (and extern "C" for C++ compilation units): you may need to add it to your source file, or #include a suitable header such as <stdlib.h> or <cstdlib>.

As described above, there are several methods you can use to insert this additional code. For a given function myfunc(), you can:

• modify the implementation of myfunc() directly, using #ifdef __CODESONAR__ ... #endif to enclose the added code, or
• add an implementation of csonar_replace_myfunc() to your software project, or
• implement csonar_replace_myfunc() in a separate file, then build and analyze a CodeSonar project that contains both your software project and this separate file.

See Manipulating the Input to the Build and Analysis for more information and examples.