[PATCH] D32905: [Analyzer] Iterator Checker - Part 9: Evaluation of std::find-like calls

Balogh, Ádám via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Sep 5 07:01:52 PDT 2018


baloghadamsoftware added inline comments.
Herald added subscribers: Szelethus, mikhail.ramalho.


================
Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:1584-1588
+  auto stateFound = state->BindExpr(CE, LCtx, RetVal);
+  auto stateNotFound = state->BindExpr(CE, LCtx, SecondParam);
+
+  C.addTransition(stateFound);
+  C.addTransition(stateNotFound);
----------------
NoQ wrote:
> We discussed this in D25660 but i couldn't find what we decided upon. It seems scary to me that in every situation, we declare that it is possible that the element is not in the container. It should be allowed, even if not necessarily efficient, to add the element to the container, and then use `std::find` to obtain an iterator to it. So i think that this state split, even if generally approved by your users, may need to stay under an analyzer checker option.
Maybe instead of an option, I should put it into a separate checker that does not emit warnings just simulates these functions, like you did it in rC284960. The file name could be `StdCppLibraryFunctions.cpp`. Common functions and macros should then be moved into a header that both `StdLibraryFunctions.cpp` and `StdCppLibraryFunctions.cpp` includes.


https://reviews.llvm.org/D32905





More information about the cfe-commits mailing list