GNU bug report logs - #20087
'gensym' is not guaranteed to return a fresh symbol

Previous Next

Package: guile;

Reported by: ludo <at> gnu.org (Ludovic Courtès)

Date: Wed, 11 Mar 2015 17:16:02 UTC

Severity: normal

Done: Andy Wingo <wingo <at> pobox.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mark H Weaver <mhw <at> netris.org>
To: rain1 <at> openmailbox.org
Cc: 20087 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
Subject: bug#20087: gensym
Date: Tue, 22 Mar 2016 01:24:26 -0400
ludo <at> gnu.org (Ludovic Courtès) writes:
> ‘gensym’ returns interned symbols, but the algorithm to determine the
> new symbol is simplistic and predictable.
> 
> Thus, one can arrange to produce a symbol before ‘gensym’ does, leading
> ‘gensym’ to return a symbol that’s not fresh (in terms of ‘eq?’), as is
> the case with the second call to ‘gensym’ here:

rain1 <at> openmailbox.org writes:
> I agree, this goes against the main assumption people have about
> gensym. I was able to reproduce the bug.
>
> Here's a patch to libguile/symbol.c which fixes this behavior by
> incrementing the gensym counter in a loop until it creates a fresh
> symbol.

I've considered this idea in the past, but it only avoids collisions
with symbols that have been interned before the gensym.  It does not
avoid collisions with symbols interned *after* the gensym.  Obviously,
there's no way to avoid such collisions.

Therefore, we must unfortunately live with the possibility of
collisions.  Furthermore, if we add a requirement for deterministic
behavior (which I think we must), then we must live with the fact that
intentional collisions can be trivially achieved.

With this in mind, I'm not sure it makes sense to add code that
attempts, but fails, to eliminate the possibility of collisions.

If we cannot eliminate the possibility of collisions, and we cannot
avoid intentional collisions, what can we do?  I think the best we can
hope for is to significantly reduce the probability of _unintentional_
collisions, perhaps by starting the gensym counter at a large number.

The other thing we can do is to clearly document these inherent problems
with gensym, so that they will not be misused for jobs for which they
are not appropriate.

What do you think?

      Mark




This bug report was last modified 9 years and 30 days ago.

Previous Next


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