Re: [PATCH] hashmap: hashmap_get_next passes through keydata as well
- Date: Sat, 13 May 2017 04:50:50 -0400
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [PATCH] hashmap: hashmap_get_next passes through keydata as well
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
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