more real-world static analysis results
Mon Oct 25 12:19:35 CEST 2004
Tobias Lindahl writes:
> As for the spurious warnings... Well, list_to_binary is a bit special and
> I will look into having a special case for it.
Dialyzer does the right thing as it is.
The documentation doesn't make any promises about what
list_to_binary/1 might do on improper lists. Some improper lists work
and some don't:
list_to_binary([1|2]) does not work
I treated that bug seperately in my previous post because, unlike the
three first bugs, it wasn't a failure of my test suite.
> I want to stress that since the aim is to have no spurious warnings
> we are really interested in knowing these things. Please send us
> all warnings that you find strange so that we can have a look at
For my codebase, Dialyzer does the right thing as it is. The warnings
from Dialyzer were all reasonable, they just weren't all bugs. Here's
a complete list (some occurred several times):
- Dialyzer complained about a caller handling more return values of
a function than the function could return. But it wasn't a bug,
it was just work-in-progress, i.e. I'd implemented support for
a new feature in one module, but not yet in another.
From the comments around the code, this was obvious, but Dialyzer
can't read comments. No problem.
- I often write
die = nyi
as a kind of assert(). Naturally, dialyzer doesn't like that.
I should write exit(nyi). Don't change Dialyzer.
- I use a compile-time preprocessor symbol to conditionally compile
case ?STARTUP_EVENT of
true -> gth_event:notify(failsafe_mode, self());
_ -> never_mind
Dialyzer sees this is a test which always goes the same way.
(If anything, I'm a bit surprised that the beam compiler didn't
optimise away the decision.)
More information about the erlang-questions