> We may use GL_LINKEDHASH_LIST and write wrappers for it (like in the
List Module).
>
> That is what I had in mind. The hash algorithms implemented in gl_list
> fit our needs (null-terminated string keys).
Are you sure ? I've read gl_list Hash code and actually I haven't found any
notion of a "string key". Rather we would need to implement the Hash
calculation
function and call gl_list_create() with a pointer to it.
Sorry. The hash function I was thinking about is in the hash-pjw
module in the gnulib:
/* Compute a hash code for a NUL-terminated string starting at X,
and return the hash code modulo TABLESIZE.
The result is platform dependent: it depends on the size of the 'size_t'
type and on the signedness of the 'char' type. */
extern size_t hash_pjw (void const *x, size_t tablesize);
Maybe it could be used as the gl_listelement_hashcode_fn. The function
is 11 lines long:
size_t
hash_pjw (const void *x, size_t tablesize)
{
const char *s;
size_t h = 0;
for (s = x; *s; s++)
h = *s + ((h << 9) | (h >> (SIZE_BITS - 9)));
return h % tablesize;
}
And it is inspired in a method described by Bruno Haible:
http://www.haible.de/bruno/hashfunc.html
So if needed would not be hard to write our own version if to use
hash_pjw with gl_listelement_hashcode_fn proves to be problematic.
Later on, we could implement the notion of an order of keys by
defining different comparision functions, one for each order type.
Yes. For "non-numeric" strings the order is given by strcmp. For the
"numeric" strings a custom function should be written down.
