Path: utzoo!attcan!utgpu!watmath!att!rutgers!ucsd!swrinde!cs.utexas.edu!think!leander.think.com!barmar
From: barmar@leander.think.com (Barry Margolin)
Newsgroups: comp.emacs
Subject: Re: possible s-expr management error (? naw, but ...)
Message-ID: <31688@news.Think.COM>
Date: 16 Nov 89 04:30:46 GMT
References: <8911160201.AA04995@NMSU.Edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA
Lines: 33

In article <8911160201.AA04995@NMSU.Edu> UNIX-EMACS@VM.TCS.Tulane.EDU writes:
>---->>>   (setq gnus-unsub-assoc (sort gnus-unsub-assoc 'gnus-assoc-lessp)))
>
>that before this line, gnus-newsrc-assoc is what it should be, but
>afterwards it has been changed.  It is approximately the right size but is
>now sorted (as if somehow the last lines of the reorder function have
>already been called).  This would not be noticable if Murphy were really
>playing games, but gnus-unsub-assoc is missing a couple of unsubscribed
>newgroups that were in the original gnus-newsrc-assoc.  They should be
>there, but since they're not the setcdr dies later.
>
>I realize this scenario is a bit hard to believe, but has anyone else seen
>something like this?  I looks to me as if the pointers for the unsub and
>newsrc lists have gotten too intermingled.  Or am I dreaming?

SORT is a destructive operation; it actually reorders the original list by
rearranging the cdr chain.  Therefore, any other references to that list
or any tail of it will see the rearrangement.

The simplest solution to this problem is to make a copy of the list before
sorting it, to guarantee that the list being sorted is not shared with
anything else.  This can be done with:

(defun copy-list (list)
  (append list nil))

The above code should then be changed to

(setq gnus-unsub-assoc (sort (copy-list gnus-unsub-assoc) 'gnus-assoc-lessp))
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar