Re: [pdf-devel] Hash module API

[jemarch]

    >    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.