Specs of reltool

Kostis Sagonas <>
Fri Oct 15 00:08:36 CEST 2010


A dialyzer user complained that he gets spurious warnings when using 
reltool functions.  A quick dialyzer run revealed that reltool is full 
of erroneous specs which cannot possibly be right.

For example, dialyzer complains that:

reltool.erl:178: The specification for reltool:get_target_spec/1 states 
that the function might also return
       {'ok',[[any()] | {_,_} | {_,_,_} | {_,_,_,_}] |
       {'copy_file',[any()]} | {'strip_beam_file',[any()]} |
       {'copy_file',[any()],[any()]} | {'create_dir',[any()],[any()]} |
       {'write_file',[any()],maybe_improper_list(any(),binary() | [])} |
       {'archive',[any()],[any()],[any()]} |
       {'create_dir',[any()],[any()],[any()]}}
but the inferred return is
       {'error',string()} | {'ok',pid()}

and indeed:

get_target_spec(PidOrOptions)
   when is_pid(PidOrOptions); is_list(PidOrOptions) ->
     eval_server(PidOrOptions, true,
		fun(Pid) -> reltool_server:gen_spec(Pid) end).

where there is a promise that eval_server/3 will return:

-spec eval_server(server(), boolean(), fun((server_pid()) -> term())) ->
  {ok, server_pid()} | {error, reason()}.


These two together cannot be right. In fact, it's easy to see that this 
function returns whatever the fun in its third argument returns (which 
is term() in this case, if one believes the 3rd argument).

In general, reltool produces many dialyzer warnings of similar kind.
They should be fixed because they are not only wrong, but they affect 
users of this application.

Kostis


More information about the erlang-bugs mailing list