NoQ added inline comments.
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?
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.
cfe-commits mailing list