| Summary: | [null][correlation]Compiler indirectly marks null pointer access | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Benno Baumgartner <benno.baumgartner> |
| Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | amj87.iitr, stephan.herrmann |
| Version: | 3.6 | Keywords: | helpwanted |
| Target Milestone: | 4.7 M1 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
I mean of course: SHOULD: I'm pretty sure b can not be null there, the compiler should _NOT_ report a problem there. (In reply to comment #1) > I mean of course: > SHOULD: I'm pretty sure b can not be null there, the compiler should _NOT_ > report a problem there. This is a part of correlation analysis which we dont currently support. You know that b cannot be null because its nullness is related to that of 'a' here because of the first if clause. So, since in the last else clause a will always be null, and because of the first if clause we know that a and b cant be together null in the last clause. I'll investigate. Bulk closing all compiler bugs tagged [null][correlation], because we have no plans to add such a feature: it would be a tremendous implementation effort, beyond our current man power, and may be impossible to achieve within the desired performance bounds. If s.o. has a viable strategy or even implementation for such a feature, I'm all ears. Verified for 4.7 M1 I created a new umbrella RFE outlining what would be needed to address this issue. *** This bug has been marked as a duplicate of bug 538421 *** |
I20100520-1744 1. Enable potential null pointer access compiler warning 2. Given public void test() { Object a= foo() ? null : new Object(); Object b= foo() ? null : new Object(); if (a == null && b == null) { System.out.println("Both are null"); } else if (a != null && b != null) { System.out.println(a.toString() + b.toString()); } else if (a != null) { System.out.println(a.toString()); } else { System.out.println(b.toString()); } } private boolean foo() { return false; } IS: The compiler marks the b in b.toString in the last else clause as potential null pointer access SHOULD: I'm pretty sure b can not be null there, the compiler should report a problem there. Yes, it is not the best code in the world but I think it is not uncommon to write something like this.