I need to debug an ugly and huge math C library, probably once produced by f2c. The code is abusing local static variables, and unfortunately somewhere it seems to
The devil is in the details, but this may work for you:
First, get Frama-C. If you are using Unix, your distribution may have a package. The package won't be the last version but it may be good enough and it will save you some time if you install it this way.
Say your example is as below, only so much bigger that it's not obvious what is wrong:
int add(int x, int y)
{
static int state;
int result = x + y + state; // I tested it once and it worked.
state++;
return result;
}
Type a command like:
frama-c -lib-entry -main add -deps ugly.c
Options -lib-entry -main add
mean "look at function add
". Option -deps
computes functional dependencies. You'll find these "functional dependencies" in the log:
[from] Function add:
state FROM state; (and default:false)
\result FROM x; y; state; (and default:false)
This lists the actual inputs the results of add
depend on, and the actual outputs computed from these inputs, including static variables read from and modified. A static variable that was properly initialized before being used would normally not appear as input, unless the analyzer was unable to determine that it was always initialized before being read from.
The log shows state
as dependency of \result
. If you expected the returned result to depend only on the arguments (meaning two calls with the same arguments produce the same result), it's a hint there may be something wrong here, with the variable state
.
Another hint shown in the above lines is that the function modifies state
.
This may help or not. Option -lib-entry
means that the analyzer does not assume that any non-const static variable has kept its value at the time the function under analysis is called, so that may be too imprecise for your code. There are ways around that, but then it is up to you whether you want to gamble the time it takes to learn these ways.
EDIT: here is a more complex example:
void initialize_1(int *p)
{
*p = 0;
}
void initialize_2(int *p)
{
*p; // I made a mistake here.
}
int add(int x, int y)
{
static int state1;
static int state2;
initialize_1(&state1);
initialize_2(&state2);
// This is safe because I have initialized state1 and state2:
int result = x + y + state1 + state2;
state1++;
state2++;
return result;
}
On this example, the same command produces the results:
[from] Function initialize_1:
state1 FROM p
[from] Function initialize_2:
[from] Function add:
state1 FROM \nothing
state2 FROM state2
\result FROM x; y; state2
What you see for initialize_2
is an empty list of dependencies, meaning the function assigns nothing. I will make this case clearer by displaying an explicit message rather than just an empty list. If you know what any of the functions initialize_1
, initialize_2
or add
is supposed to do, you can compare this a priori knowledge to the results of the analysis and see that something is wrong for initialize_2
and add
.
SECOND EDIT: and now my example shows something strange for initialize_1
, so perhaps I should explain that. Variable state1
depends on p
in the sense that p
is used to write to state1
, and if p
had been different, then the final value of state1
would have been different. Here is a last example:
int t[10];
void initialize_index(int i)
{
t[i] = 1;
}
int main(int argc, char **argv)
{
initialize_index(argv[1][0]-'0');
}
With the command frama-c -deps t.c
, the dependencies computed for initialize_index
are:
[from] Function initialize_index:
t[0..9] FROM i (and SELF)
This means that each of the cells depends on i
(it may be modified if i
is the index of that particular cell). Each cell may also keep its value (if i
indicates another cell): this is indicated with the (and SELF)
mention in the latest version, and was indicated with a more obscure (and default:true)
in previous versions.