Original bug ID: 5290
Hashtbl.hash returns 0 on custom blocks, at least those of the standard library (verified on bigints, channels, and by a cursory grep). This is consistent with its documentation "associates a positive integer to any value of any type". However, it is IMHO a very poor choice, as this will always silently lead to abysmal performances when this function is used on such values. It would be more logical to have this function fail, just as polymorphic equality and comparison. Since Hashtbl are about to undergo a massive rewrite in 3.13, please consider deprecating the old behavior and have the function fail.
(For the record, this really bit us. After some reorganization, we started using the polymorphic hashing function, and Frama-C performances dropped terribly. It took us one afternoon to track the culprit.)
(Also, providing a good hash function for bigints/nats, one bound in the custom block, would be great. For example, keep only the 2^(n-1) lowest or highest bits. This cannot be done efficiently in pure Caml.)
The text was updated successfully, but these errors were encountered: