more real-world static analysis results

[Matthias Lang]

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
   list_to_binary([1|<<2>>]) works

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
 > them.

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
    code, i.e.

      case ?STARTUP_EVENT of
         true -> gth_event:notify(failsafe_mode, self());
          _ -> never_mind
      end,

     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.)

Matthias