This patch is made upon user request. The first example is the following:
int f(int n) { return n; } int main() { int v[3], i; v[0] = 0; v[2] = 2; for(i = 0; i<3; ++i) { f(v[i]); } return 0; }
Here we get warning that parameter v[i] is uninitialized when calling f(). However, it is not clear in the bug path for which i is this true. In the example v[1] is uninitialized. Our patch adds a note to the bug path: Assuming i == 1.
Another user complained about false positive here:
static unsigned size = 32; int init(int *s); void assert(int); static void test(void) { int val; if (size>10) { for (unsigned j = 0; j<size+1; j++) init(&val); assert((int) (val == 1)); } }
At the assert() statement we get warning for garbage value. This looks impossible for the first site, however, with our patch we get a note at the beginning of the loop: Assuming j == 0, size == 4294967295. Now it is clear that val is indeed uninitialized in case of an integer overflow in size.
This patch is still preliminary, only part of the tests is adjusted. First we try to reduce the unnecessary noise, by e.g. removing duplicate messages.
Questions to consider:
- Name of the Visitor. Currently it is VariableValuesBRVIsitor, maybe a better one could be found.
- Maybe we shoud use is insted of == to make it compatible with ConditionBRVisitor.
- Currently we add the note to the last appearance of the variable before the bug. Maybe we should change it to the first appearance where the variable takes its final value.