Re: Emacs-diffs Digest, Vol 19, Issue 62

[Kim F. Storm]

Richard Stallman <address@hidden> writes:

> Why is this necessary?

I don't know ... anybody else have a clue?

The reason I added it is that I had SEVERE problems with emacs
misbehaving or crashing with the initial version of this patch.

One "misbehaviour" was that reading mail with Gnus suddenly would
signal not-a-list errors when going from one message to another.  I
guess that Gnus uses quite large lists to keep track of the messages I
have read -- and convert that information to/from text, so I would
guess it uses mapconcat or mapcar in that process, and thus triggers
the new code...

I then added the "dogc" stuff to the Lisp_Save_Value so that GC scans
the allocated memory.  (I'm on GNU/Linux which uses the MARK_STACK GC
method).

After adding the GC awareness, those crashes went away, so I thought I
better add GCPROs for the non-MARK_STACK case as well.

But you are right that it looks superfluous ... 

> 
>     diff -c emacs/src/fns.c:1.367 emacs/src/fns.c:1.368
>     *** emacs/src/fns.c:1.367 Tue Jun 22 13:57:00 2004
>     --- emacs/src/fns.c       Tue Jun 22 14:48:10 2004
>     ***************
>     *** 3020,3026 ****
>     --- 3020,3030 ----
>       for (i = 1; i < nargs; i += 2)
>         args[i] = separator;
> 
>     +   GCPRO1 (*args);
>     +   gcpro1.nvars = nargs;
>       ret = Fconcat (nargs, args);
>     +   UNGCPRO;
>     + 
>       SAFE_FREE_LISP (nargs);
> 
> As far as I know, Feval can't be called from Fconcat, so GC
> cannot occur there.
> 
>     +   GCPRO1 (*args);
>     +   gcpro1.nvars = leni;
>       ret = Flist (leni, args);
>     +   UNGCPRO;
>     + 
> 
> Same issue there.
> 
> 

-- 
Kim F. Storm <address@hidden> http://www.cua.dk