more real-world static analysis results
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:
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.
More information about the erlang-questions