[PATCH] D25475: [analyzer] Add a new SVal to support pointer-to-member operations.

[Artem Dergachev via cfe-commits]

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