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.

cfe-commits mailing list

Reply via email to