Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 131455

Summary:

[compiler][null][correlation] two variables synchronized null status

Product:

[Eclipse Project] JDT

Reporter:

x y <m8r-eehfmm>

Component:

Core

Assignee:

Ayushman Jain <amj87.iitr>

Status:

CLOSED DUPLICATE

QA Contact:

Severity:

enhancement

Priority:

CC:

stephan.herrmann

Version:

3.2

Keywords:

helpwanted

Target Milestone:

4.7 M1

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
screenshot with problem code and warning	none

Description x y

2006-03-12 07:38:27 EST

Variable b cannot be null, but Eclipse 3.2M5a doesn't think so :(

if ( (a == null) != (b == null) || a != null && a.length != b.length)
{
     // do something
}

Comment 1 x y

2006-03-12 07:40:14 EST

Created attachment 36103 [details]
screenshot with problem code and warning

Comment 2 Maxime Daniel

2006-03-13 05:11:36 EST

The proposed code warns upon b, with a "may be null" message.
b is tainted by the first test, which tells the analysis that the developer thinks that b may be null.
A human reader recognizes that b.length is a legitimate call is all cases because at the call point, a != null and per the first condition, then b != null. But our current analysis does not attempt to draw from (a == null) != (b == null) any conclusion regarding a relationship between a and b. (Something like: 'if this expression is true, then a and b have the same null status'.) Hence the warning.

This is an expected limitation of the current analysis. It may be reconsidered in the future.

Comment 3 Maxime Daniel

2007-06-19 08:06:54 EDT

Reopening as P5 (since RESOLVED LATER is deprecated).

Comment 4 Stephan Herrmann

2016-06-28 17:18:24 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 5 Sasikanth Bharadwaj

2016-08-02 04:37:02 EDT

Verified for 4.7 M1

Comment 6 Stephan Herrmann

2018-08-30 10:37:56 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 ***