GNU bug report logs -
#36447
27.0.50; New "Unknown keyword" errors
Previous Next
Full log
View this message in rfc822 format
On Fri, Jul 5, 2019 at 12:33 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> Thanks for the explanations. I'm CC'ing Stefan who knows much more
> about this than I do.
Thank you.
> > The reasons are this: when a hash table is purecopied, its ->next
> > vector is purecopied, which merges it with another, similar, hash
> > table's ->next vector if purify-flag is a (third) hash table. The
> > vectors are compared using `equal', but the pure copies are actually
> > `eq'.
>
> A naïve question: wouldn't the problem go away if we modified purecopy
> not to do the above, i.e. not to merge the next vector of a hash table
> with that of another?
I thought about that, but it's a bit complicated: either we'd keep the
->next vector impure (and make a copy of it), or we would have to add
a "don't hash-cons" argument to purecopy(), which kind of defeats the
purpose.
> > The (disappointingly trivial) fix:
> > call copy-sequence on h->next before rehashing the table.
>
> Rehashing is not only done during dumping, right?
As far as I can tell, it's only done when first accessing a dumped
hash table, but I might be wrong. (In any case, it seems
`hash-table-count' then returns a negative value for the hash table,
which seems problematic to me.)
> So the fix you
> propose also makes rehashing slightly less efficient. Is that
> necessary, i.e. are you saying that the bug is in rehashing, not in
> purecopy?
Again, I may be wrong, since we're using the sign of h->count to
indicate whether a hash table needs rehashing and that's hard to grep
for, but I think this only affects rehashing after dump, not rehashing
when resizing a hash table. It's certainly not called very often, and
not for very large hash tables.
This bug report was last modified 5 years and 316 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.