GNU bug report logs - #75521
scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 75521 <at> debbugs.gnu.org
Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX
Date: Mon, 13 Jan 2025 19:37:37 +0000

"Stefan Kangas" <stefankangas <at> gmail.com> writes:

> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> Patch:
>
> Thanks!  Your patch seems to make things both safer and simpler.

That's the first patch, right?  If Eli wants to keep never-used Lisp
APIs stable and prefers a minimal change, we should do that, but we
should also fix the comment in alloc.c:

diff --git a/src/alloc.c b/src/alloc.c
index 8307c74c106..6a72e8aa087 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7405,9 +7405,7 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL()		((void) 0)
 		/* If the value is forwarded to a buffer or keyboard field,
 		   these are marked when we see the corresponding object.
 		   And if it's forwarded to a C variable, either it's not
-		   a Lisp_Object var, or it's staticpro'd already, or it's
-		   reachable from font_style_table which is also
-		   staticpro'd.  */
+		   a Lisp_Object var or it's staticpro'd already.  */
 		break;
 	      default: emacs_abort ();
 	      }

> I'm curious why this was considered worth optimizing in the first place.

So am I.  It seems particularly strange to me that this was considered
an optimization at all: make-docfile.c could simply have moved all
global variables into a contiguous section, and then we wouldn't need
to staticpro them individually.  Also irrelevant on today's machines,
of course.

(staticpro is a bit strange for another reason: are you supposed to call
it while the variable is uninitialized?  If the initialization
expression calls Lisp, that might GC, and GC shouldn't see uninitialized
values.  But if you call it after initializing the variable, you're
putting data into unprotected memory, which is also something that
should raise an alarm.  Right now, both approaches are okay and in use,
but that's inconsistent.  That's why I proposed changing staticpro to
have two arguments quite a while back.)

Pip

Previous Next

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