On Wed, May 28 2025, Pip Cet wrote:

> "Helmut Eller" <eller.helmut@gmail.com> writes:
>
>> Making the Lisp_Obarray.buckets field a proper Lisp_Vector instead of a
>> plain Lisp_Object[] would make some things simpler: some #ifdef HAVE_MPS
>> can be removed and the dumper is a bit simpler too.
>
> Or we could make it a Lisp_Object, and use the generic vectorlike code.
> I really do not understand your reasoning for wanting to do the
> opposite, and use more raw pointers in heap objects.  What is the
> advantage?

The advantage is better static type checking and better documentation.
Compare the field declarations:

  struct Lisp_Vector *buckets;

with
  
  Lisp_Object buckets;

Which one describes the data structure better?  Clearly the first.

[...]
> I realize there's no consensus for following my suggestion (if it's on
> the heap, and thus fixable, use a Lisp_Object; if you need a raw
> pointer, it should only ever be in a local variable).  But I don't think
> there's any consensus for doing the opposite either.

I think that in structures, raw pointers to objects on the GC heap will
not go away.  So we can as well take advantage of them.

[...]
> As for less fundamental things that should probably be fixed:
>
> I notice that vector_size doesn't mask out the GC mark bit, but it is
> used instead of gc_asize in the new AREF.  So the new AREF is
> problematic when used during GC.
[...]
> The pdumper code should probably use strong weight for the bucket
> vector, not WEIGHT_NORMAL, in order to avoid changing the dump layout
> unpredictably.
[...]
> Since size_bits and the size of the new vectors are redundant, it'd be
> nice to assert things are as they should be in obarray_size.

Valid points.  See amended patch below.