Community
Participate
Working Groups
I20060301-0800 boolean bite(Integer aaa, Integer bbb) { return (aaa == null && bbb == null) || (aaa.byteValue() == bbb.byteValue()); } Second reference to aaa has wrong warning: "The variable aaa may be null". aaa cannot be null, since the right hand side of || would never have been entered then.
If I change the && to &, both aaa and bbb get the warning.
Adding line numbers for clarity: 1 boolean bite(Integer aaa, Integer bbb) { 2 return (aaa == null && bbb == null) 3 || (aaa.byteValue() == bbb.byteValue()); 4 } Assuming that aaa is null and bbb is not, aaa == null yields true, bbb == null yields false, hence the condition of line 2 is false and we enter the condition of line 3 with aaa null. The warning on aaa is right. Now, we miss the warning on bbb.
<blush> You're right, and with &, both warnings are correct. BTW: I found the pattern when debugging bug 130317 (I now filed bug 130330 for the bogus null check).
I discussed this with Philippe on my way home and he pointed out that we are correct not to complain on bbb (in the && case). If bbb is null, then: - either aaa is also null and we return from line 2 with true; - or else aaa is not null and we return from line 2 with false (without evaluating bbb against null, btw). Hence we're right not to report that bbb may be null on line 3. With &, this is another story, since aaa non null bbb null is a valid combination that goes to line 3.
Try harder... My second case above is wrong. If aaa is non null, then we go to line 3 without having evaluated bbb against null. This results into bbb not being suspect of being null, hence no warning (that is, we evaluate the expression before returning, instead of returning immediately as I stated above). As a result, we cannot infer on line 4 that bbb is non null, which shows up in the following test case, in which we have no warning on line 3: 1 boolean bite(Integer aaa, Integer bbb) { 2 return (aaa == null && bbb == null) 3 || bbb == null; 4 } (if we could decide that bbb is definitely non null, we should warn so.) The question that is left open is should we be conservative, and keep the algorithm as it is, or try to infer from the expression on line 3 that the developer does not trust bbb not to be non null? I keep the conservative approach for now.
