Bugzilla – Full Text Bug Listing
| Summary: | [compiler] [null] Inconsistent handling in null-analysis ( && and || ) | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Axel Groß <axel.gross> |
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | stephan.herrmann |
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
(In reply to comment #0) > 1) Non-Null seems to be default for in-params (see fooA method) unless some > doubt is shed (by checking for nullity). Is that changeable somehow? Without null annotations, the default state for arguments is "unknown". As long as we know nothing we will not flag *any* use of a variable. By contrast a known-nonnull value will trigger a warning in comparison against null (redundant), which we also don't do for "unknown". > 2) Null analysis does not shed doubt in case of second argument of > and-operators; see the difference in fooAnd and fooOr. I find this very > surprising. > > [...] > static String fooOr(String producesError, String producesError2) { > if (producesError == null || producesError2 == null) { > } // doubt on both > return producesError.toString() + producesError2.toString(); > } > > static String fooAnd(String producesError, String producesNoError) { > if (producesError == null && producesNoError == null) { > } // doubt only on producesError!!! > return producesError.toString() + producesNoError.toString(); > } Well, || and && are not symmetric, but you're right, this is not a good excuse for the results you observed. I'll take a look. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Two issues with static null-analysis (the first one may be a misunderstanding on my side): 1) Non-Null seems to be default for in-params (see fooA method) unless some doubt is shed (by checking for nullity). Is that changeable somehow? 2) Null analysis does not shed doubt in case of second argument of and-operators; see the difference in fooAnd and fooOr. I find this very surprising. static String foo(String producesNoError1, String producesNoError2) { return producesNoError1.toString() + producesNoError2.toString(); } static String fooOr(String producesError, String producesError2) { if (producesError == null || producesError2 == null) { } // doubt on both return producesError.toString() + producesError2.toString(); } static String fooAnd(String producesError, String producesNoError) { if (producesError == null && producesNoError == null) { } // doubt only on producesError!!! return producesError.toString() + producesNoError.toString(); }