Pip Cet wrote:

> I don't think this eassert () is completely safe.  pure_alloc will
> return uninitialized memory if pure space has overflowed, so it's
> possible the new table is marked as mutable.

Good point. I wonder what other code has similar problems? Rather than spend 
time looking for that, I installed the first attached patch, which clears that 
uninitialized memory. If pure space is going away anyway I'm not sure it's worth 
the trouble to audit the code for similar problems elsewhere.

> Is it really necessary to cater to code such as this? I thought the
> general line was that it was okay for bad Lisp code to crash Emacs in
> exceptional circumstances, such as by building bad bytecode objects or
> by doing silly things in a user-defined hash function...

Generally speaking Emacs should not crash. There is currently an exception for 
bad bytecode objects, but we really should fix that (presumably by verifying the 
bytecode before executing it, to avoid slowdown during execution).

While we're on the topic, we should better document how user-defined hash 
functions should behave. I installed the second attached patch to do that. It 
also clarifies that hash codes are fixnums.

By code inspection I found some problems that I recently introduced, involving 
very large hash tables and/or 32-bit platforms --with-wide-int, and fixed them 
with the third attached patch.