Community
Participate
Working Groups
Build Identifier: 20110218-0911 "Null Pointer Access" triggered for following code Reproducible: Always Steps to Reproduce: public class TestFile { public void doTest() { byte[] buffMem = null; byte[] buffFile = null; for (int i = 0; i < 10; i++) { if (buffMem == null) { buffMem = new byte[10]; buffFile = new byte[10]; } if (buffFile.length > 16) { // <<< warning here } } } }
This case is a bit complicated. The warning is not correct, nor can we say that it is entirely wrong (that's why its only a "potential" warning). The warning is a result of initializing buffFile inside an if statement which is true only for 1 iteration of the loop. So, the compiler sees it as either initialized or not initialized depending on whether the if is true or false in any given iteration. Ofcourse, for a human reader it is straightforward to see that buffFile will always be initialized in the first iteration itself since the if statement is true in the 1st iteration. Yet for the compiler this isn't a trivial task. I will classify this under correlation analysis since the nullness of buffFile is correlated with that of buffMem here. We don't do correlation analysis in null analysis currently.
Simplified test case: It can be demonstrated without the for loop, but you are correct, it is a correlation analysis problem. public class TestFile { public void doTest(byte[] buffMem) { byte[] buffFile = null; if (buffMem == null) { buffMem = new byte[10]; buffFile = new byte[10]; } if (buffFile.length > 16) { // <<< warning here } } }
(In reply to comment #2) > > public class TestFile > { > public void doTest(byte[] buffMem) { > byte[] buffFile = null; > > if (buffMem == null) { > buffMem = new byte[10]; > buffFile = new byte[10]; > } > if (buffFile.length > 16) { // <<< warning here > } > } > } Actually the warning is correct in this case. This is because the if statement can either be true or be false, but we are not able to determine that path because we dont know what value will be passed to the parameter when doTest is called. But the same logic fails in the for loop case because for atleast 1 iteration of the loop, we can deterministically tell the execution path.
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 ***
