Bug 321304 - [null][correlation]Compiler indirectly marks null pointer access
Summary: [null][correlation]Compiler indirectly marks null pointer access
Status: CLOSED DUPLICATE of bug 538421
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 enhancement (vote)
Target Milestone: 4.7 M1   Edit
Assignee: Ayushman Jain CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2010-07-30 04:47 EDT by Benno Baumgartner CLA
Modified: 2018-08-30 10:35 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benno Baumgartner CLA 2010-07-30 04:47:47 EDT
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.
Comment 1 Benno Baumgartner CLA 2010-07-30 04:48:45 EDT
I mean of course:
SHOULD: I'm pretty sure b can not be null there, the compiler should _NOT_ report a problem there.
Comment 2 Ayushman Jain CLA 2010-07-30 05:09:55 EDT
(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.
Comment 3 Stephan Herrmann CLA 2016-06-28 17:17:56 EDT
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.
Comment 4 Sasikanth Bharadwaj CLA 2016-08-02 04:51:01 EDT
Verified for 4.7 M1
Comment 5 Stephan Herrmann CLA 2018-08-30 10:35:54 EDT
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 ***