> 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.
I think It won't be problematic.
Nice.
Now, I'll send the patch for the final Hash Module API that I'm planing to
implement.
A question first. Regarding "pdf_hash_iterator_next()" that is supposed to
return each key of a hash table, do you think we should keep track of each
string key and free() them when "pdf_hash_iterator_free()" is called or leave
the user that job. It is a memory used over complexity trade-off.
If possible I would offer the keys to the user under the form of a
const pointer. The pointer would directly point to the pdf_hash_t
internal string that conforms the key.
The API seems ok to me. Please commit it and ACK.
Thanks.
