kromanenkov added inline comments.
================ Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:2314 { + // Return to fulfil assert condition + if (location.getAs<nonloc::PointerToMember>()) ---------------- NoQ wrote: > Hmm. Why would anybody try to load anything from a plain pointer-to-member, > rather than from a pointer-to-member-applied-to-an-object (which would no > longer be represented by a `PointerToMember` value)? I suspect there's > something wrong above the stack (or one of the sub-expression `SVal`s is > incorrect), because otherwise i think that making `PointerToMember` a NonLoc > is correct - we cannot store things in it or load things from it. Brief analysis shows that we call evalLoad of pointer-to-member SVal after ExprEngine::VisitCast call when cast kind is CK_LValueToRValue. Skipping this check leads to assertion fail in pointer-to-member.cpp test. I will investigate the other ways to supress this assertion. ================ Comment at: test/Analysis/pointer-to-member.cpp:79 // FIXME: Should emit a null dereference. return obj.*member; // no-warning } ---------------- NoQ wrote: > In fact, maybe dereferencing a null pointer-to-member should produce an > `UndefinedVal`, which could be later caught by > `core.uninitialized.UndefReturn`. I wonder why doesn't this happen. In fact, I plan to caught dereferencing of null pointer-to-members by the checker which I intend to commit after this patch :) So, do you think that the check for dereferencing a null pointer-to-member should be a part of an analyzer core? https://reviews.llvm.org/D25475 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits