[bug #22022] hashx-set! and -ref

[Neil Jerram <INVALID.NOREPLY@gnu.org>]

Follow-up Comment #3, bug #22022 (project guile):

And here are all the remaining ones.  I've added a (pk ...) in each case, so
the output from make check shows what the actual hash?-ref value was.

;;; (#f)
FAIL: hash.test: auto-resizing hashx: (equal? (quote eq) (pk (hashq-ref table
4)))

;;; (#f)
FAIL: hash.test: auto-resizing hashx: (equal? (quote equal) (pk (hashx-ref
hash equal? table 1/32)))

;;; (#f)
FAIL: hash.test: auto-resizing hashx: (equal? (quote eqv) (pk (hashx-ref
hashv eqv? table 1/33)))

;;; (#f)
FAIL: hash.test: auto-resizing hashx: (equal? (quote eq) (pk (hashx-ref hashq
eq? table 34)))

These cases, together with the neighbouring ones that happen to pass, are
actually out of scope, because the manual says (5.6.12.2 Hash Table
Reference):

-----------manual------------
Like the association list functions, the hash table functions come in
several varieties, according to the equality test used for the keys.
Plain `hash-' functions use `equal?', `hashq-' functions use `eq?',
`hashv-' functions use `eqv?', and the `hashx-' functions use an
application supplied test.

   A single `make-hash-table' creates a hash table suitable for use
with any set of functions, but it's imperative that just one set is
then used consistently, or results will be unpredictable.
-----------manual------------

The rationale for this is what happens when a hash table is resized.  When
that happens, the new hash buckets (vector indices) are recalculated, for all
existing entries in the table, using the hash function that was specified on
the call that caused the resize.  If that hash function is different from the
hash that is later used to try to query particular entries, Guile can look in
the wrong bucket, and the expected entry won't be found.

There's another case, too, where a rehash is done following GC, using a hash
function that was stored at some point in the hashtable data structure.  But I
haven't got right into that, because I think we already have enough to rule
these test cases invalid.

What do you think?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?22022>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/