RedDocMD added a comment.
> Does the following test work?
@NoQ, it seems to be working.
> So you're saying that simply by always tracking the (final) raw pointer value
> and checking whether the raw value is interesting upon .get() you dodge the
> communication problem entirely
I would not say it has been dodged, but rather that problem had already been
solved by `trackExpressionValue`. At line 1949 of BugReporterVisitors.cpp
(inside the `trackExpressionValue` function) is:
if (LVState->getAnalysisManager().getAnalyzerOptions().ShouldTrackConditions)
report.addVisitor(std::make_unique<TrackControlDependencyCondBRVisitor>(
InputNode));
Approximately, `TrackControlDependencyCondBRVisitor` is a visitor that looks
into condition statements and via mutual recursion with `trackExpressionValue`
marks SVal's as interesting if they are used in a condition and that condition
constrains the `Expr` on which the visitor was originally called on. This gave
me the idea that calling `trackExpressionValue` is all that we really need to
do, since it already contains a visitor to discover the interestingness we
need. Looking into this function made me feel that `trackExpressionValue` is
actually a very powerful function which solves a lot of these communication
problems.
> Do i understand correctly that this doesn't happen anymore when you stopped
> creating a new node?
Yes, and I found out my blunder after staring at the exploded graph dump.
Creating a new node was un-necessary since `trackExpressionValue` needs a node
corresponding to the expression where we find the bug, and that was already
being created above.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D97183/new/
https://reviews.llvm.org/D97183
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
