[LispM] bug in hash-table-rehash?

[Greg Gilley]

This is in the MIT sys99 code and the Explorer code:

	((null grow) (setq hash-table (follow-structure-forwarding hash-table))
		     (setf (hash-table-lock new-hash-table) (hash-table-lock hash-table))
		     (%blt-typed (%find-structure-leader new-hash-table)
				 (%find-structure-leader hash-table)
				 (%structure-total-size hash-table) 1)
		     (return-array (prog1 new-hash-table (setf new-hash-table nil)))
		     hash-table)

In the function hash-table-rehash, if it didn’t grow the table (after a gc perhaps), then it copies the re-hashed table back to the original hash table.

However, it doesn’t seem to copy the whole table. if I read the comments from the microcode (this is from sys99, but seems similar to the lmi microcode):


;;; Given the address of the base of a structure, return information on its size.
;;; Note that if given the address of an array header, the leader (if any) is
;;; not counted, but if given the address of the leader, the leader is
;;; counted.  I.e. nothing before the given address is counted.
;;; In the case of an RPLACD-forwarded list, the 2 words pointed to by the
;;; forwarding-pointer are counted, and the forwarding-pointer itself isn't.

It looks as though it’s not copying the complete hash table over because it’s passing in the pointer to the hash-table and the not the hash-table leader.

Anyone familiar enough with the code to confirm my diagnosis?

Thanks,

	Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/lispm/attachments/20180311/dbcea3f1/attachment.html>