Re: Bug in GHash

[Jeff Garzik <jgarzik pobox com>]

On 23 Jan 1999, Owen Taylor wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
> > One major and one minor bug in ghash:
> > 
> > * g_hash_table_insert _overwrites_ whatever is in the current bucket
> > with the new value.  (it should instead append to a list)
> 
> I don't think so.
> 
> On failure g_hash_table_lookup_node() returns a pointer tail
> of the list for the bucket. (By common sense, hash tables
> are not badly broken. They are used all over the place
> in GTK+ and the GIMP)

Previous to my change, g_hash_table_insert() never touched the 'next'
field of the hash node list at all.  But after I wrote that message I
saw that g_hash_table_resize() correctly maintained the linked list.

So, the possibility of nodes being overwritten was very real, but
periodically calls to _resize() would repair most of the damage.


> > * Some of the other g_hash_table_* functions support multiple values for
> > a single key, but g_hash_table_insert comment states (implicitly) that
> > if a key/value pair is inserted and the key already exists, the new
> > value overwrites the old value on the same key.

> How does it make any sense to have multiple values for
> a single key? A hash table is a 1-1 lookup function ...

Take a look at STL's multimap class, which implements a key/value lookup
ADT supporting multiple values for a single key.  But by your answer I
will assume ghash is meant to be a 1-1 lookup.  :)

	Jeff