[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