Null dereference analysis in practice

Many analysis techniques have been proposed to determine when a potentially null value may be dereferenced. But we have observed in practice that not every potential null dereference is a "bug" that developers want to fix. In this paper we discuss some of the challenges of using a null dereference analysis in practice, and reasons why developers may not feel it necessary to change code to prevent ever possible null dereference. We revisit previous work on XYLEM, an interprocedural null dereference analysis for Java, and discuss the challenge of comparing the results of different static analysis tools. We also report experimental results for XYLEM, Coverity Prevent, Fortify SCA, Eclipse and FindBugs, and observe that the different tools tradeoff the need to flag all potential null dereferences with the need to minimize the number of cases that are implausible in practice. We conclude by discussing whether it would be useful to extend the Java type system to distinguish between nullable and nonnull types, and prohibit unchecked dereferences of nullable types.