v4.9.2

Fixes

• A size at the limit produced an unusable table. Two independent faults, both at max_size(), both found by asking whether a test would notice a bug rather than whether it ran the line:

  • calc_shifts_for_size() walked the shift down past the point where the bucket array can still grow. calc_num_buckets() saturates at max_bucket_count(), so above max_bucket_count() * max_load_factor() the capacity being compared stopped growing while the loop kept decrementing — all the way to a shift of zero, where calc_num_buckets() asks for 1 << 64. That is undefined and in practice one: a table sized for billions of elements came back with a single bucket and a mask of zero, and the next probe read past the end of it. Reachable from rehash(), which does not allocate the values and so has nothing to fail first — map<uint32_t, uint32_t>::rehash(3865470566) reproduced it.
  • replace() and clear_and_fill_buckets_from_values() counted in value_idx_type. max_size() is exactly what that type can hold, so a container of precisely that many has a size that is not representable in it: the cast wrapped to zero, the loop never ran once, and the table came back reporting size() elements with no bucket pointing at any of them. (#192)

• The bucket type's contract is now checked at compile time. The fingerprint must fit strictly below dist_inc, and dist_inc must be a power of two. Both were always required — the probe arithmetic adds dist_inc expecting it to touch only the distance — but nothing said so, and a custom Bucket violating either failed at run time in ways that looked like a hashing bug. This only affects code supplying its own bucket type, and only where it was already broken. (#192)

No API changes. Everything else since v4.9.1 is tests, tooling and CI, which does not reach anyone consuming the header.

Full Changelog: v4.9.1...v4.9.2