Re: MPS: Forwording symbols

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Helmut Eller <eller.helmut@gmail.com> writes:

> 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.

Sounds like a good plan to me.

Maybe we could also make predicate an enum at the same time? It need not
be a Lisp_Object, and replacing it with an enum would make that clearer.