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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75521 <at> debbugs.gnu.org, eliz <at> gnu.org, stefankangas <at> gmail.com
Subject: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX
Date: Mon, 13 Jan 2025 14:27:01 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>>
>>>> Cc: stefankangas <at> gmail.com
>>>> Date: Sun, 12 Jan 2025 22:36:12 +0000
>>>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>>>
>>>> Also on master, the single user of DEFVAR_LISP_NOPRO is questionable:
>>>> font.c doesn't staticpro Vfont_weight_table because it appears in
>>>> font_style_table, but then font_style_table is sometimes modified so it
>>>> points to a new vector, and I don't see how Vfont_weight_table is
>>>> protected then.
>>>
>>> According to this comment:
>>>
>>>   /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_table. */
>>>   static Lisp_Object font_style_table;
>>>
>>> Vfont_weight_table is actually an element of font_style_table, and
>>> that one is protected:
>>
>> But then font_style_table is sometimes modified so it points to
>> (i.e. contains as its element) a new vector, and I don't see how
>> Vfont_weight_table is protected then.
>>
>> Pip
>
> BTW, this is _exactly_ how the old GCPRO macro was used. "We don't need
> to GCPRO this local variable here because it's already protected by
> something else".

Indeed.  I played around with GC shortly before GCPRO was removed,
thinking (naively) that almost all Lisp_Objects that needed to survive
GC were GCPRO'd, and we would be able to use that for precise GC.  But
GCPRO only ever protected the value of a Lisp_Object, never its address,
making it useless for other purposes.

> That caused me such pain debugging
> that I added conservative stack marking, split off the SDATA from
> strings and so on. I'd hope Emacs overcomes this.

I'm thinking of these changes as removing the last (hopefully) remnants
of GCPRO:

1. Remove DEFVAR_LISP_NOPRO
2. Conservatively mark SAFE_ALLOCA'd memory
3. Conservatively mark SDATA pointers so they remain valid

The problem with (3) is that pin_string becomes unnecessary for
correctness then, and it would be nice to remove it, but I suspect that
it is still necessary for performance: there are a lot of bytecode
objects, and while we might hope that most of them live in the "old"
sblocks that aren't copied, I don't think that's always true.  (My
implementation reorders sdata a little but not by more than one sblock.
It'd be easy to change that not to reorder sdata at all, but then we'd
see fragmentation).

However, that still doesn't fix make_environment_block, which uses
xmalloc.  So we'd have to xstrdup there; or make some xmalloc'd memory
conservatively scanned; or rewrite it to be a macro which calls
SAFE_ALLOCA.

Pip

Previous Next

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