Path: potomac!daemon
From: daemon@potomac
Newsgroups: slug-info
Subject: Submission for slug-info
Message-ID: <166@potomac.dc.ads.com>
Date: 21 Jan 87 07:21:01 GMT
Sender: daemon@potomac.dc.ads.com
Lines: 58
Path: potomac!daemon
From: garza@ghostwheel.DB.MCC.COM
Newsgroups: slug-info
Subject: Symbolics (Genera 7) BUG
Message-ID: <155@potomac.dc.ads.com>
Date: 21 Jan 87 04:12:00 GMT
Sender: daemon@potomac.dc.ads.com
Lines: 44
There is a bug in Symbolics Common Lisp (Genera 7.0) when one calls
remhash in the body of the maphash function. Guy Steele (page 285) points
out that if entries are added/deleted from a hash table while maphash is in
progress the results are unpredictable unless the function calls remhash to
------
remove the entry currently being processed.
Test::
(setq x (make-hash-table))
(dotimes (i 100)
(setf (gethash i x) i))
(maphash #'(lambda (k v) (format t "~% k = ~d v = ~d" k v)) x)
(maphash #'(lambda (k v) (remhash k x)) x)
(maphash #'(lambda (k v) (format t "~% k = ~d v = ~d" k v)) x)
The hash table should now become empty, but it is found to be not so.
However, if one indicates that the '= comparator is desired during
the allocation of the hash table, it works fine.
(setq x (make-hash-table :test #'=))
(dotimes (i 100)
(setf (gethash i x) i))
(maphash #'(lambda (k v) (format t "~% k = ~d v = ~d" k v)) x)
(maphash #'(lambda (k v) (remhash k x)) x)
(maphash #'(lambda (k v) (format t "~% k = ~d v = ~d" k v)) x)
Now the table is empty, as it should be.
PS: The above bug does not happen under Rel 6.
Jorge F. Garza