[erlang-bugs] Dialyzer v2.2.0 crash

Kostis Sagonas kostis@REDACTED
Sun May 1 17:53:51 CEST 2011


Peer Stritzinger wrote:
> On Sun, May 1, 2011 at 4:49 PM, Kostis Sagonas <kostis@REDACTED> wrote:
>> Peer Stritzinger wrote:
> 
> BTW: is it normal not to get any warnings when just doing --annotate
> in typer and then dialyzer with no manually tweaked spec's 

Yes. In fact, typer is just a front end for dialyzer's basic type 
inference (i.e. without the warning identification component).

IMO, there is very little point in doing this if you do not intend to 
manually "massage" the specs that you get and provide more info for some 
of them.  Take a look at your previous program.  The fact that the two 
<<_:64,_:_*8>> types were referring to the same quantity could be 
expressed better if you introduced a type as in:

   -type packet() :: <<_:64,_:_*8>>,

Similarly for channel:

   -type channel() :: atom() | pid() |{atom(),_}.

and then the spec would already look better.  Also, dialyzer/typer has 
no info on what type of fun you intend to use in the second argument of 
function recv/3 but you do!  From the code it is clear that it takes 
#can_pkt{} record, so why don't you add appropriate types to its fields 
and introduce a type for it?

   -record(can_pkt, {id :: id(), data :: binary(), timestamp :: ts()}).
   -type can_pkt() :: #can_pkt{}.

then the specs can look much better:

   -spec recv(packet(), fun((can_pkt()) -> R), channel()) -> R.
   -spec decode(packet()) -> can_pkt().

and note that I've used a placeholder type variable R to denote the fact 
that function recv/2 returns whatever type the fun in its second 
argument returns. You probably know what this type is so you should also 
introduce a type for it and use its proper name.

Hope this helps,
Kostis

PS. It's a pity you posted this in erlang-bugs as the information 
contained in the above is IMO more interesting than the actual bug.



More information about the erlang-bugs mailing list