Re: Trying to track down an alpha problem (may be in scm_ihashq).

[Carl R. Witty]

Rob Browning <address@hidden> writes:

> Here's my modified for debugging version of scm_ihashq
> 
>   unsigned int
>   scm_ihashq (SCM obj, unsigned int n)
>   {
>     unsigned int result;
>     unsigned long unpack = SCM_UNPACK(obj);
>     result = (SCM_UNPACK (obj) >> 1) % n;
>     fprintf(stderr, "scm_ihashq (%lu >> 1) %% %u -> %u\n", unpack, n, result);
>     fflush(stderr);
>     return result;
>   }
> 
> and at the point of failure, this prints:
> 
>   scm_ihashq (18446744073709551614 >> 1) % 31 -> 4294967295

I'll bet that SCM_UNPACK(obj) has type "long" (that is, "signed
long").  In that case, according to the rules of ANSI C, on machines
where sizeof(long) > sizeof(int), "n" is promoted to long and the "%"
is signed.  On machines where sizeof(long) == sizeof(int),
"SCM_UNPACK(obj) >> 1" is converted to unsigned long and the "%" is
unsigned.  (In other words, it uses signed "%" on Alphas and unsigned
"%" on x86 and other 32-bit platforms.)

You almost certainly want unsigned "%" here.  One way to do that would
be:

  result = ((unsigned long)(SCM_UNPACK (obj) >> 1)) % n

On the other hand, I believe that SCM_UNPACK (obj) was changed to
return unsigned in a CVS checkin last night (am I correct in assuming
that SCM_UNPACK results in something of type scm_t_bits?), so the
current CVS version should be working here anyway.

Carl Witty