On Fri, May 12, 2017 at 01:02:44PM -0700, Stefan Beller wrote: > The 'keydata' may be of value in the underlying compare function to decide > if the given two entries are the same. I had to scratch my head over this for a minute, because there isn't really any motivating example of what you're trying to do. I think I figured it out, but I have a feeling it is violating the intent of the "keydata" parameter. That parameter is typically used not as a pointer to arbitrary auxiliary data, but as a trick for finding a hash entry without having to allocate a struct for it. So generally, I'd think two entries in the table should be able to be compared on their own merits, even if no keydata is available. Without that property, any internal operations in the hashmap can't actually do an entry comparison (e.g., a table resize that needs to rehash the entries). It works out in the current code because the chaining is purely linear, and doesn't care about order. So we can rehash and just stick the elements into a new list. But if it were switched out for a different data structure (e.g., a tree), then the hashmap code would need to be able to compare elements. I don't think we have any particular plans for such a change, but I wonder if we should avoid encouraging callers to rely on the current implementation. -Peff