Bug 300239 - Loop confuses null pointer analysis
Summary: Loop confuses null pointer analysis
Status: CLOSED DUPLICATE of bug 293917
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.6 M5   Edit
Assignee: Ayushman Jain CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-20 13:33 EST by Remy Suen CLA
Modified: 2010-01-22 09:51 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Remy Suen CLA 2010-01-20 13:33:57 EST 
Build id: I20100119-0800

public void v(Object o) {
  while (true) {
    o.toString(); // claims it may be null
    if (o != null); // claims it can't be null
  }
}

public void v2(Object o) {
  o = new Object();
  while (true) {
    o.toString(); // claims it may be null
    if (o != null); // claims it can't be null
  }
}

If you delete the if statement, then the warning on the toString() call will disappear.
Comment 1 Srikanth Sankaran CLA 2010-01-20 23:53:55 EST 
Ayush, please investigate.
Comment 2 Ayushman Jain CLA 2010-01-22 01:10:35 EST 
I think this got fixed with bug 293917. 
Remy, can you apply the patch given in bug 293917 and check again? I dont get the spurious warnings on the toString() call anymore.
Comment 3 Remy Suen CLA 2010-01-22 09:21:40 EST 
(In reply to comment #2)
> I think this got fixed with bug 293917. 
> Remy, can you apply the patch given in bug 293917 and check again? I dont get
> the spurious warnings on the toString() call anymore.

The bug does not occur with N20100121 so I guess the problem has been resolved (indirectly?).

*** This bug has been marked as a duplicate of bug 293917 ***
Comment 4 Ayushman Jain CLA 2010-01-22 09:51:08 EST 
Yes this is has been fixed. 

Earlier, whenevr a null check was done against a local variable, it got 'tainted' and marked as maybe null. Since in a loop, null check warnings are always deferred till the end of the loop, at the time of deciding whether o in o.toString() is null or not, it'd have already got unnecessarily tainted by the if statement. Hence the warning.

This unnecessary tainting of local variables is done away with now.