NoQ added inline comments.
================ Comment at: test/Analysis/pointer-to-member.cpp:79 // FIXME: Should emit a null dereference. return obj.*member; // no-warning } ---------------- kromanenkov wrote: > 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? That'd be great! However, we're doing a lot of such double-work in case a checker to find the defect is not enabled. For example, as seen by `ExprEngine`, result of division by zero, or of reading past an array bound, or of reading an unitialized variable, is `UndefinedVal`. For division by zero and for reading past an array bound, there's a checker that immediately terminates the analysis when the error occurs, which makes it completely irrelevant how exactly `ExprEngine` models the erroneous operation. In case of array bound, however, this checker is alpha and disabled by default. For reading an unitialized variable, no checker immediately warns, and `UndefinedVal` proceeds to exist until it is actually used anywhere. So i think this tradition is worth keeping, and the result of null pointer-to-member dereference should first be modeled as `UndefinedVal`. More importantly, however, it is worth investigating why doesn't it already magically happen. I suspect it might be related to the other problem of loading from a non-loc. https://reviews.llvm.org/D25475 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
