rnkovacs added inline comments.
================
Comment at: lib/StaticAnalyzer/Checkers/InnerPointerChecker.cpp:192
- if (Call.isCalled(CStrFn) || Call.isCalled(DataFn)) {
- SVal RawPtr = Call.getReturnValue();
- if (SymbolRef Sym = RawPtr.getAsSymbol(/*IncludeBaseRegions=*/true)) {
- // Start tracking this raw pointer by adding it to the set of symbols
- // associated with this container object in the program state map.
- PtrSet::Factory &F = State->getStateManager().get_context<PtrSet>();
- const PtrSet *SetPtr = State->get<RawPtrMap>(ObjRegion);
- PtrSet Set = SetPtr ? *SetPtr : F.getEmptySet();
- assert(C.wasInlined || !Set.contains(Sym));
- Set = F.add(Set, Sym);
- State = State->set<RawPtrMap>(ObjRegion, Set);
- C.addTransition(State);
+ SVal Arg = FC->getArgSVal(ArgI);
+ const auto *ArgRegion =
----------------
NoQ wrote:
> xazax.hun wrote:
> > While I cannot recall examples in the STL the number of arguments and
> > parameters might differ. We might have ellipsis in the parameters and this
> > way we may pass more arguments. Since we do not have the parameter type for
> > this case, I think it is ok to not handle it. But it might be worth to have
> > a comment. The other case, when we have default arguments. I do not really
> > know how the analyzer behaves with default arguments but maybe it would be
> > worth to add a test case to ensure we do not crash on that?
> The analyzer behaves pretty badly with default arguments; we don't really
> model them unless they are like plain integer literals. But that's not an
> issue here because a default parameter/argument is still both a parameter and
> an argument (where the argument expression takes the form of
> `CXXDefaultArgExpr`).
Hm, it seems that passing objects of non-trivial types like `std::string` to a
variadic function is implementation defined, and for `clang 6.0`, this means
that it does not compile (does compile with `gcc 8.1` though, [[
https://godbolt.org/g/C3MCtV | example ]]).
Added a test for the default parameter case.
https://reviews.llvm.org/D49656
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
