Re: MPS: Forwording symbols

[Helmut Eller <eller.helmut@gmail.com>]

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.