GNU bug report logs - #36447
27.0.50; New "Unknown keyword" errors

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, npostavs <at> gmail.com, 36447 <at> debbugs.gnu.org
Subject: bug#36447: 27.0.50; New "Unknown keyword" errors
Date: Fri, 05 Jul 2019 15:33:10 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 5 Jul 2019 09:09:13 +0000
> Cc: michael_heerdegen <at> web.de, npostavs <at> gmail.com, 36447 <at> debbugs.gnu.org
> 
> > Sorry, I don't think I know what "this bug" is about,
> 
> The bug:

Thanks for the explanations.  I'm CC'ing Stefan who knows much more
about this than I do.

> 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?

> The (disappointingly trivial) fix:
> call copy-sequence on h->next before rehashing the table.

Rehashing is not only done during dumping, right?  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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.