Erick:
This isn't about garbage collection this time!
I have encountered a couple of problems with the hash
table implementation. I think they are genuine
bugs, but if so, then I don't understand how they
worked before. Again, we are still on 3.99.4.
In hash_table_put, when the type of the hash table
is hash_comp, then the result of applying it to
the key is used as an argument to Tcl_FindHashEntry as follows:
(This quote is from the 4.0.0 sources).
index = Apply1(HASH_SXHASH(ht), key);
if ((entry=Tcl_FindHashEntry(HASH_H(ht), (char *) index)) != NULL) {
The hash function is expected to return an integer, so surely
it is wrong to use the SCM value. Shouldn't this use
the integer value of index instead? For example:
case hash_comp:
index = Apply(HASH_SXHASH(ht), LIST1(key));
nIndex = STk_integer_value(index);
if ((entry=Tcl_FindHashEntry(HASH_H(ht), (char *) nIndex)) != NULL) {
When I made this change I immediately ran into a second
problem. In make_hash_table if a hash function is not
supplied then it gets the value:
sxhash = the_func("hash-table-hash");
The problem is that the_func creates a SCM value as follows:
else { /* s is "hash-table-hash" */
NEWCELL(z, tc_subr_1);
z->storage_as.subr0.f = (SCM (*)()) sxhash;
where sxhash is a static function declared as:
unsigned long sxhash(SCM obj)
Thus the_func seems to create a SCM function that returns an
unsigned long, whereas it should create a function that returns
a SCM value.
I fixed this one by replacing the above lines in the_func
by:
else { /* s is "hash-table-hash" */
NEWCELL(z, tc_subr_1);
z->storage_as.subr0.f = (SCM (*)()) hash_table_hash;
Does this seem right to you? It certainly makes everything work!
Paul.
______
Paul Anderson. GrammaTech, Inc. Tel: +1 607 273-7340
mailto:paul_at_grammatech.com
http://www.grammatech.com
Received on Mon Apr 17 2000 - 18:08:15 CEST