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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
