[cfe-dev] Fwd: Tracking Values in the Clang Static Analyzer

scott constable sdconsta at syr.edu
Wed Jul 1 08:00:34 PDT 2015


Clang Experts,

I'm interested in using the CSA to track various aspects and properties of
values in C++ programs. For example, if I decide that a value or object
should be colored blue, then it should remain blue throughout its life in
the translation unit. So far, I've been using the following map with some
degree of success:

REGISTER_MAP_WITH_PROGRAMSTATE(ColorMap, const MemRegion *, Color)

So rather than coloring the values, I'm coloring their associated memory.
Furthermore, when blue memory is copied to another location, the target
location is also colored blue (using checkBind). In the following typical
case, my strategy works fine:

void foo (int *j) {
    *j += 3; // in this statement, color the memory pointed to by j "blue"
    return;
}

void bar () {
    int i = 42;
    foo(&i);
    i -= 3; // in this statement, i is still "blue"
}

But the following will NOT work:

int foo (int j) {
    j += 3; // in this statement, color j's memory "blue"
    return j;
}

void bar () {
    int i = 42;
    int k = foo(i);
    k -= 3; // in this statement, k is not "blue", though I want it to be
}

The reason why this doesn't work is that in the second example, j is
returned by foo() by value, meaning it's copied, and so the k inside bar()
no longer refers to the same (blue) memory region. This would be fine if
checkBind() were to catch such copies, but apparently it does not. The same
problem arises when variables are passed by value to a function. For
example, if I had colored i blue in bar() before calling foo(i), then i
would no longer be blue inside foo();

My second approach was to also allow for the coloring of SVal's:

REGISTER_MAP_WITH_PROGRAMSTATE(ColorSValMap, SVal *, Color)

But this led to other problems, because apparently SVal's are not unique,
and are recycled. So a lot of values were being incorrectly labeled as blue.

Any help would be very much appreciated. BTW I'm using Clang 3.5.

~Scott Constable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150701/cc2cf3d1/attachment.html>


More information about the cfe-dev mailing list