[Chicken-users] Incorrect hash-table-size for copied hash tables

[John Croisant]

I have discovered a bug in hash-table-copy and/or hash-table-size.

If you copy a non-empty hash table, hash-table-size will report that the
copy has 0 entries. But if you use hash-table-ref, hash-table->alist, 
etc. you will see that the copy actually has all the expected entries. 
The only thing incorrect is the size reported by hash-table-size.

It seems like an internal counter is being initialized to 0 in the copy,
when it should be the same value as the original hash table. Adding a
new entry to the copy increases the size by 1, setting an existing entry
has no effect on the size, and deleting an entry decreases the size by
1. That behavior is normal, but because the counter starts at 0, the
size can become negative, which is nonsense. :)

I'm seeing this bug in Chicken 4.7.0 and 4.7.3 (from Git) on Linux. I'm
having trouble compiling Chicken >4.7.3, so I don't know if this bug
still exists in the latest code from Git.


Example:

#;1> (use srfi-69)
; loading library srfi-69 ...
#;2> (define h1 (alist->hash-table '((0 . 1) (2 . 3) (4 . 5))))
#;3> h1
#<hash-table (3)>
#;4> (hash-table-size h1)
3
#;5> (define h2 (hash-table-copy h1))
#;6> h2
#<hash-table (0)>
#;7> (hash-table-size h2)
0
#;8> (hash-table->alist h2)
((4 . 5) (2 . 3) (0 . 1))
#;9> (hash-table-set! h2 6 7)
#;10> (hash-table->alist h2)
((6 . 7) (4 . 5) (2 . 3) (0 . 1))
#;11> (hash-table-size h2)
1
#;12> (hash-table-set! h2 4 8) ; <-- replace entry for 4
#;13> (hash-table-size h2)
1
#;14> (hash-table-delete! h2 0)
#t
#;17> (hash-table-size h2)
0
#;18> (hash-table-delete! h2 2)
#t
#;19> (hash-table-size h2)
-1