[erlang-bugs] Re: [erlang-questions] picky dialyzer

Mikael Pettersson <>
Tue Jan 18 14:42:48 CET 2011

Kostis Sagonas writes:
 > Björn Gustavsson wrote:
 > > 2011/1/14 Kostis Sagonas <>:
 > > 
 > > The crash is in hipe_unified_loader. It crashes the code_server
 > > process before it has found out that there is no native code
 > > to load.
 > > 
 > >> I can of course investigate and possibly correct this throughout but I am
 > >> also wondering: is this 0..256 a sane choice? Why on earth one would have
 > >> such a range? Wasn't Erlang exotic enough without this feature? :-)
 > > 
 > > The 0..256 range was an arbitrary choice decided long before
 > > there was a Dialyzer.
 > > 
 > > Actually, I am willing to change the range to 0..255 in the next
 > > release in order to keep the Dialyzer type simple and beautiful.
 > > I don't think that there is any code depending on a function
 > > having 256 arguments, so that change should be safe.
 > Thanks Bjorn!
 > I also think this is safe and in any case it's a change for the better.
 > Actually, it's not dialyzer which is what's difficult to change here, 
 > but more finding out all places in the hipe compiler and loader where 
 > there might be implicit assumptions that the function's arity can always 
 > be stored in a byte.

I distinctly remember that Björn once said that the max arity was 255,
though he may have said 256.  I always interpreted it as 255, implying
that a byte suffices, since 256 seemed like a totally arbitrary limit.

The only things I _know_ break if the limit is 256 are:
- hipe_{x86,amd64}.c emit "movb $Arity, ..." insns in the native code
  wrappers for BEAM functions, and hipe_arm.c similarly is limited to
  an 8-bit immediate for the arity
- there are a few type checks on MFAs in the HiPE runtime system
  that check that the arity doesn't exceed 255

The first breakage is real and I'd hate to have to emit 32-bit
immediates there.  The other breakage is superficial and can easily
be repaired if necessary.

If Björn's willing to lower the max arity from 256 to 255 then I'm all
for that solution.


More information about the erlang-questions mailing list