emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: Forwording symbols


From: Helmut Eller
Subject: Re: MPS: Forwording symbols
Date: Fri, 21 Jun 2024 17:36:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

On Sun, Jun 16 2024, Gerd Möllmann wrote:

> Ok, I've looked a bit closer, and I think we can avoid dumping the
> the forwarding structs altogether.
>
> There are 5 types of forwarding structs
>
>  enum Lisp_Fwd_Type
>    {
>      Lisp_Fwd_Int,            /* Fwd to a C `int' variable.  */
>      Lisp_Fwd_Bool,           /* Fwd to a C boolean var.  */
>      Lisp_Fwd_Obj,            /* Fwd to a C Lisp_Object variable.  */
>      Lisp_Fwd_Buffer_Obj,     /* Fwd to a Lisp_Object field of buffers.  */
>      Lisp_Fwd_Kboard_Obj              /* Fwd to a Lisp_Object field of 
> kboards.  */
>    };
>
> Four of them contain only the type and either integer offsets or
> pointers to variables in Emacs' data segment. The only interesting one
> is Lisp_Fwd_Buffer_Obj which looks like
>
>   struct Lisp_Buffer_Objfwd
>     {
>       enum Lisp_Fwd_Type type;        /* = Lisp_Fwd_Buffer_Obj */
>       int offset;
>       /* One of Qnil, Qintegerp, Qsymbolp, Qstringp, Qfloatp or Qnumberp.  */
>       Lisp_Object predicate;
>     };
>
> which has an additional member for the predicate. AFAICT, the comment is
> true, and thus predicate is also a constant because it is always from a
> DEFSYM, i.e. it is a symbol from lispsym.

Can we use similar reasoning to remove fix_fwd?  If predicate is
guaranteed to be a builtin symbol, then we don't need to do anything for
the Lisp_Buffer_Objfwd case.

Then only remains issue with DEFVAR_LISP_NOPRO.  We could simply make
DEFVAR_LISP_NOPRO an alias for the regular DEFVAR_LISP.

If fix_symbol needs to call fix_fwd, then so should fix_blv.  But nicer
would be to remove fix_fwd altogether.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]