[PATCH] D73898: [analyzer] StdLibraryFunctionsChecker: Add argument constraints

Fri Feb 7 08:45:48 PST 2020

martong added a comment.

In D73898#1864066 <https://reviews.llvm.org/D73898#1864066>, @martong wrote:

> In D73898#1863710 <https://reviews.llvm.org/D73898#1863710>, @Szelethus wrote:
>
> > I wouldn't like to see reports emitted by a checker that resides in `apiModeling`. Could we create a new one? Some checkers, like the `IteratorChecker`, `MallocChecker` and `CStringChecker` implement a variety of user-facing checkers within the same class, that is also an option, if creating a new checker class is too much of a hassle.
>
>
> ... And actually it makes sense to apply the argument constraints only if we know for sure that they are not violated. ...

What I mean by that is that we must do over-approximation if the argument is symbolic. I.e. we presume that the constraints do hold otherwise the program would be ill-formed and there is no point to continue the analysis on this path. It is very similar to what we do in case of the DivZero or the NullDeref Checkers: if there is no violation (no warning) and the variable is symbolic then we constrain the value by the condition. E.g. in DivZero::checkPreStmt we have:

  // If we get here, then the denom should not be zero. We abandon the implicit
  // zero denom case for now.
  C.addTransition(stateNotZero);

Strictly speaking, these transitions should be part of the modeling then in this sense (and they should be in PostStmt?). Still they are not separated into a different checker.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73898/new/

https://reviews.llvm.org/D73898