[Analyzer] Does SymbolicRegion preserve the structure of its associated memory?

Clang Frontend Static Analyzer
1

Hi All,

Suppose I’m analyzing the following code:

struct MyStruct {
int a;
int b;
int c;
};

void foo(MyStruct &s) {
…
}

Furthermore, suppose that I would like to annotate s.b’s memory in the program state, without also annotating s.a and s.c. When I retrieve the region referenced by s, I observe that it is a SymbolicRegion, which is to be expected. I cannot, however, see any way to reason about any of its SubRegions individually, in this case s.a, s.b, and s.c.

I understand that SymbolicRegions are supposed to represent memory regions whose values the analyzer cannot properly model. But it still should be able to recognize that from foo’s point of view, s has a well-defined structure with three FieldRegions, though their values must be symbolic.

Any help would be very much appreciated.

~Scott Constable

2

Hi Scott,

Subregion relationships are one-to-many, and they are constructed lazily as memory can be arbitrary re-interpreted when analyzing a path because of casts, etc. If you want to model a binding to ‘MyStruct’, you can construct the FieldRegion yourself using MemRegionManager’s getFieldRegion(), but I don’t know if that’s the solution you are looking for here.

Can you explain what you are trying to do in more detail? I may be able to help you better with more specifics.

Ted

3

Ted,

I’m doing an taint-like analysis which requires reasoning across translation units, so I’m doing a phase 1 analysis where I output summary information for each translation unit, and then a phase 2 analysis where I use that summary information to produce bug reports. For instance, if I have the following code:

// TU.h

struct MyStruct {
int a;
int b;
int c;
};
void foo(MyStruct &s);

// TU1.cpp
#include TU.h
void bar() {
MyStruct t {1, 2, 3};
foo(t);
}

// TU2.cpp
#include TU.h
void foo(MyStruct &s) {
…
}

For whatever reason, during the analysis of TU1.cpp t.b’s memory might become “tainted”. When bar() calls foo(), this taint information is written to a summary text file. In phase 2, at the very beginning of the analysis of TU2.cpp, I load the summary information from phase 1, and observe that a call was made to foo such that s.b should be treated as tainted. So I would like to mark s.b’s memory as such.

I don’t think that getFieldRegion() is what I’m looking for, because (I believe) it does not update the program state with the construction of the new FieldRegion.

Thanks for your help,

~Scott