Bug 4906 – Dereferencing null error in a single expression

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2010-09-21T04:44:16Z
Last change time
2024-12-13T17:53:28Z
Keywords
accepts-invalid
Assigned to
No Owner
Creator
bearophile_hugs
Moved to GitHub: dmd#17515 →

Comments

Comment #0 by bearophile_hugs — 2010-09-21T04:44:16Z
To find null dereferencing in code the compiler probably needs to perform flow analysis. But the compiler can spot and flag as errors at compile-time expressions that follow explicit comparisons to null: if (obj is null && obj.foo()) { ... Where the programmer probably meant to write: if (obj !is null && obj.foo()) { ... Or: if (obj is null || obj.foo()) { ... This test doesn't cover several cases of dereference null errors that span different lines of code, but the cases it covers seem common enough to me. See also bug 4595 See also bug 4571 See also: http://code.google.com/intl/en-EN/webtoolkit/tools/codepro/doc/features/audit/audit_rules_com.instantiations.assist.eclipse.auditGroup.semanticErrors.html#com.instantiations.assist.eclipse.analysis.audit.rule.dereferencingNullPointer
Comment #1 by andrej.mitrovich — 2012-12-09T09:11:03Z
(In reply to comment #0) > To find null dereferencing in code the compiler probably needs to perform flow > analysis. > But the compiler can spot and flag as errors at compile-time expressions that > follow explicit comparisons to null: > > > if (obj is null && obj.foo()) { ... What if 'foo' is a UFCS function? There's a slight possibility that such a check was expected. I guess the compiler could be more lax in the UFCS case and more careful if 'foo' is actually a method, so maybe this is implementable..
Comment #2 by robert.schadek — 2024-12-13T17:53:28Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17515 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB