Alex's response below informs us why you get an error on 32-bit but
not on 64. The error can only occur when there's an equivalent hash
in the table (in hash-table-update!). On a 32-bit system, only the
last 8 string chars are significant so reg_effective_date and
reg_ineffective_date hash to the same value. On a 64-bit system, the
last 16 chars are significant and the hash values are different.
Kon's procedure-check patch is a good idea but I don't want to touch
trunk right now.
A trivial change to improve the hash function (C_hash_string) would
probably change
while(len--) key = (key << 4) + *(str++);
to while(len--) key += (key << 5) + *(str++);
(which extends significance to arbitrary length, and allows power of 2
table sizes instead of prime table sizes)
I don't want to try this until after the release of 3.0 though.
On Jan 24, 2008 10:31 AM, Alex Shinn <[EMAIL PROTECTED]> wrote:
> The reason it doesn't signal an error right away is because if the
> keys hash to different values, then they fall into fresh, empty
> buckets and there's no other elements to compare against.
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
