GNU bug report logs - #68244
hash-table improvements

Previous Next

Full log

Message #208 received at 68244 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <acorallo <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, dmitry <at> gutov.dev, 68244 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: Re: bug#68244: hash-table improvements
Date: Sat, 24 Feb 2024 10:45:03 +0100

15b6d72599b9 on master:

> +If you have code which creates obarrays as a simple Lisp vector:
> +
> +   (make-vector N nil)
> +
> +and then calls 'intern' using such an obarray as second argument, this
> +will now signal a wrong-type-argument error; replace nil with zero to
> +make it work again.

Thank you Eli, this might be useful, and you are absolutely right that we should help users fix their code.

But this cannot have come from nowhere. Did anyone actually tried to create obarrays in this broken way? It goes against all previous documentation and violates many invariants at once: it would have filled an obarray with multiple copies of the nil symbol which itself is interned in a different obarray.

Running `mapatoms` would have given very surprising results (what does nil have in its .u.s.next pointer? what happens if we remove nil from this pseudo-obarray?) and it must have been a recipe for accidents. It cannot have been a widespread usage.

And if anyone did try to create an obarray in that incorrect way, better recommend using `obarray-make` which is more future-safe than an already obsolete form.

Previous Next

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