Commit Graph

6 Commits

Author SHA1 Message Date
Jordan Rose f7f32d5202 [analyzer] Teach FindLastStoreBRVisitor to understand stores of the same value.
Consider this case:

  int *p = 0;
  p = getPointerThatMayBeNull();
  *p = 1;

If we inline 'getPointerThatMayBeNull', we might know that the value of 'p'
is NULL, and thus emit a null pointer dereference report. However, we
usually want to suppress such warnings as error paths, and we do so by using
FindLastStoreBRVisitor to see where the NULL came from. In this case, though,
because 'p' was NULL both before and after the assignment, the visitor
would decide that the "last store" was the initialization, not the
re-assignment.

This commit changes FindLastStoreBRVisitor to consider all PostStore nodes
that assign to this region. This still won't catches changes made directly
by checkers if they re-assign the same value, but it does handle the common
case in user-written code and will trigger ReturnVisitor's suppression
machinery as expected.

<rdar://problem/13299738>

llvm-svn: 176201
2013-02-27 18:49:57 +00:00
Ted Kremenek 37c777ecc0 [analyzer] Use 'MemRegion::printPretty()' instead of assuming the region is a VarRegion.
Fixes PR15358 and <rdar://problem/13295437>.

Along the way, shorten path diagnostics that say "Variable 'x'" to just
be "'x'".  By the context, it is obvious that we have a variable,
and so this just consumes text space.

llvm-svn: 176115
2013-02-26 19:44:38 +00:00
Anna Zaks 58b961d176 [analyzer] Plist: change the type of issue_hash from int to string.
This gives more flexibility to what could be stored as issue_hash.

llvm-svn: 171824
2013-01-08 00:25:22 +00:00
Ted Kremenek a5958869f6 TrackConstraintBRVisitor and ConditionBRVisitor can emit similar
path notes for cases where a value may be assumed to be null, etc.
Instead of having redundant diagnostics, do a pass over the generated
PathDiagnostic pieces and remove notes from TrackConstraintBRVisitor
that are already covered by ConditionBRVisitor, whose notes tend
to be better.

Fixes <rdar://problem/12252783>

llvm-svn: 166728
2012-10-25 22:07:10 +00:00
Jordan Rose 92375adafb [analyzer] Allow ObjC ivar lvalues where the base is nil.
By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.

This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.

This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.

llvm-svn: 164960
2012-10-01 19:07:22 +00:00
Jordan Rose 1d64a49855 [analyzer] Check that an ObjCIvarRefExpr's base is non-null even as an lvalue.
Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:

  PointObj *p = nil;
  int *px = &p->_x; // should warn here
  *px = 1;

llvm-svn: 164442
2012-09-22 01:24:38 +00:00