[PATCH] D70805: [analyzer] SValHasDescendant: Determine whether the SVal has an SVal descendant
Csaba Dabis via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Dec 9 20:21:25 PST 2019
Charusso added a comment.
In D70805#1776527 <https://reviews.llvm.org/D70805#1776527>, @NoQ wrote:
> Usually this kind of code is hard to re-use because all use cases require different definitions of "has descendant". We already have at least 3 such definitions floating around and we can't re-use them.
>
> Even in the world of ASTMatchers the actual `hasDescendant` matcher is basically an anti-pattern as you always want to use a matcher for a //specific// parent-child relation instead (cf. http://lists.llvm.org/pipermail/cfe-dev/2019-September/063260.html).
When I encounter the following:
unsigned Foo = Foo.Bar[Baz]->Qux;
malloc(strlen(src) + Foo + 1);
At the moment I cannot lookup the `strlen(src)` and nor the `+ 1`. There is no way to say the `strlen(src)` which parent is a `malloc()`. I do not think we could make the full support of pattern-matching on symbolic level, so at least I wanted to see if it is possible. I am even thinking of using the ASTImporter to normalize the expression so that in a flatten/serialized form the AST-matcher could look for such constructs without any wonky `DeclRefExpr` or `ReturnStmt` matching. I believe the latter is the way we could benefit a lot, and the former, the current patch needs to be eliminated. For now I cannot relax the AST or invent a symbolic-matcher language so I would prefer this simple workaround and may we will have better ideas later.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70805/new/
https://reviews.llvm.org/D70805
More information about the cfe-commits
mailing list