[cfe-commits] [PATCH] A tentative implementation of RegionStoreManager
Ted Kremenek
kremenek at apple.com
Mon Oct 6 22:07:14 PDT 2008
On Oct 6, 2008, at 9:10 PM, Zhongxing Xu wrote:
> A new patch attached. In this patch, we introduce a
> AnonPointeeRegion to represent the assumed pointee of parameter or
> global pointers.
>
> Another scheme: we assume nothing about parameter or global
> pointers, just give them a symbolic value, as we do in the
> BasicStore. Then we will not bother this AnonPointeeRegion and the
> unknown MemSpaceRegion. What do you think of this?
> <pointeeregion.patch>
Having an AnonPointeeRegion seems like a great first step, although I
think in the long term just have symbolic values for globals and
parameters has some appeal as well. In the case of symbolic values,
what happens in cases like the following:
void foo(int *p, int *q) {
*p = 1;
*q++;
}
Does 'p' bind to a symbolic value upon entry, and after "*p" we lazily
create a region for it and then bind the value '1' to that region?
What about 'q'? If we determine that 'p' and 'q' alias each other, do
we unify their regions/symbols? I believe that thinking about
questions like these help make the design choices a little clearer.
I'm not looking for a perfect solution, but aliasing relationships are
something we need to consider. Most bug-finding tools assume that
pointers of the same type are not aliased because this is the case 90%
of the time. We can also lazily "assume" aliasing relationships, just
like we do with pointers that are potentially null.
For example, GRExprEngine makes no assumptions about the nullness of
'p' upon entry to the function, and records an "implicit null
dereference" to 'p' in the case that 'p' was null:
void (int* p) {
*p = 1;
}
Clients can then go over the analysis results and look for implicit-
null dereferences; if the client knows that a parameter value could be
null, we have the opportunity to flag a warning. This is exactly what
we do in CheckNSError.cpp.
Similarly, aliasing relationships could be handled the same way, with
bugs on paths stemming from conservative reasoning about aliases being
ranked lower (or suppressed than other bugs) until we know that 'p'
and 'q' could actually alias each other (for example).
More information about the cfe-commits
mailing list