Re: bug -- duplicate entries in the custom.dic cause assert


Subject: Re: bug -- duplicate entries in the custom.dic cause assert
From: Mike Nordell (tamlin@algonet.se)
Date: Mon Feb 05 2001 - 07:39:50 CST


Sam TH wrote:
>1) The root cause is that somehow, my custom.dic got a duplicate
>entry. This shouldn't ever happen, since once you add something, it
>should stay added, and you shouldn't get a chance to add it again. I
>haven't the foggiest idea how this happened, but it wasn't normal. I
>can't reproduce it.

No matter what, it has been added, and AW shouldn't "die" on this IMO (which
is what we do if we _really_ let an assert "do its stuff").

> 2) Once you have a duplicate entry, Abi generates an assert every time
> you start up.

I think this is OK. But, AW should _in addition_ to telling us developers
"this sucks" also fix this _after asking the user if it's OK to fix it_!
(e.g. "AbiWord found a duplicate entry for your custom dictionary. Do you
want to repair this?"). The only obvious answer is "Yes", but at least it
displays AW is going to change something and it's not doing this behind the
users back. I don't know if the computer-illiterate (i.e. church secretary)
neither understands nor cares about this, but I know that I'd surely do.

> The question is, should we keep this assert?

Yes.

> I would think that it shouldn't be a UT_SHOULD_NOT_HAPPEN
> case to try to add the same key to a hash table twice. What do
> other people think?

If our hash table is really a "map" where the hash is the "key" for that
map, it _is_ and error to add two values with the same "key". On the other
hand, if our hash table is a hash table this is not an error. We only have a
collision where we would have to add that new entry to a "bucket". I.e., the
hashtable should accept multiple entries with the same has-value, but
*never* accept entries with the same "key".

Could this be an error in the code using the hashtable, that it really wants
a _map_, not a hashtable type "map"?

> The code that asserts is in ut_alphahash.cpp:68. It looks like this:

... shit^H^H^H^Hcrap? Don't get me started on *that* code. That code is IMHO
a problem in itself.

/Mike



This archive was generated by hypermail 2b25 : Mon Feb 05 2001 - 07:38:16 CST