================
@@ -212,6 +212,25 @@ typedef llvm::ImmutableMap<const LocationContext *,
unsigned>
REGISTER_TRAIT_WITH_PROGRAMSTATE(PendingArrayDestruction,
PendingArrayDestructionMap)
+// This trait is used to heuristically filter out results produced from
+// execution paths that took "weak" assumptions within a loop.
+REGISTER_TRAIT_WITH_PROGRAMSTATE(SeenWeakLoopAssumption, bool)
+
+ProgramStateRef clang::ento::recordWeakLoopAssumption(ProgramStateRef State) {
+ return State->set<SeenWeakLoopAssumption>(true);
+}
+
+bool clang::ento::seenWeakLoopAssumption(ProgramStateRef State) {
+ return State->get<SeenWeakLoopAssumption>();
+}
----------------
NagyDonat wrote:
The example
```cpp
void foo(int x, int y) {
for (unsigned i = 0; i < x; i++) ; // split the state and set
SeenWeakLoopAssumption to 'true'
if (x != 0) return; // drop the 'true' branch
// no warnings are reported from this point on
}
```
is a very good point and I'll probably add it to the tests to highlight this
limitation of the heuristic.
However, I've seen {{ArrayBoundV2}} reports where lots of stuff happens between
the point where we assume that a loop can have 0 iterations (i.e. some
length/size variable is equal to 0) and the point where this triggers an
unwanted report; so I don't think that we can have a natural cutoff where the
"SeenWeakLoopAssumption" bit may be safely cleared.
I don't see a way to avoid these kinds of false negatives without a completely
different loop handling approach, so I think we should accept them in the
foreseeable future. (There are already lots of precedents for losing coverage
after loops.)
https://github.com/llvm/llvm-project/pull/109804
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
