more real-world static analysis results

Luke Gorrie luke@REDACTED
Mon Oct 25 12:53:07 CEST 2004


Tobias Lindahl <tobias.lindahl@REDACTED> writes:

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

I ran it on a large codebase and it reported lots of unsafe bytecode
warnings asking me to recompile with a newer compiler. I'd like to
filter these out because it's not convenient to upgrade the compiler
right now, but I couldn't find the filtering options in the GUI. Are
they there somewhere in the released version?

Dialyzer also hung during startup the first time because I didn't have
Tk installed on my machine.

> Also, we are really interested in knowing about bugs you find that
> is _not_ found by Dialyzer, but that you think should have been, so
> that we can make an effort to find them.

I have one vague feature desire but I don't think it could be done in
a non-false-positive way. Suppose I have a module containing some
typos in atoms:

  -module(foo).
  -compile(export_all).

  send(P) -> P ! oaky.
  recv()  -> receive acknolwedge -> ok end.

It might be nice to warn that send/1 sends 'oaky' but that this atom
doesn't appear as a constant in any receive (or that it doesn't appear
as a constant anywhere at all), and likewise for receiving
'acknolwedge'. Of course list_to_atom can introduce false positives.

I mention this just because there have been some whispers around the
office of defining all atom constants as macros to avoid typo-errors,
and I would really hate to do that.

Cheers,
Luke





More information about the erlang-questions mailing list