bug#41321: 27.0.91; Emacs aborts due to invalid pseudovector objects

[Eli Zaretskii <eliz@gnu.org>]

> Cc: pipcet@gmail.com, 41321@debbugs.gnu.org, monnier@iro.umontreal.ca
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 30 May 2020 12:14:14 -0700
> 
> On 5/30/20 11:21 AM, Eli Zaretskii wrote:
> 
> > on current emacs-27, both LISP_ALIGNMENT
> > and alignof(max_align_t) are 16 in my builds.  And I still don't
> > understand why using LISP_ALIGNMENT of 8 is not right in this case (on
> > emacs-27).
> 
> You're right that LISP_ALIGNMENT is 16 on your host on the emacs-27 
> branch, because alignof (max_align_t) is 16 there. And you're also right 
> that setting LISP_ALIGNMENT to be 8 on your host would fix the marker 
> bug you observed there, because it would work around your host's bug 
> where malloc returns a pointer that is not a multiple of 
> alignof(max_align_t). However, C and POSIX allow platforms where 
> LISP_ALIGNMENT should be greater than 8, or (if !USE_LSB_TAG) should be 
> less than 8, so I'd be leery about changing LISP_ALIGNMENT on any host 
> that doesn't have your host's idiosyncrasies.

Posix may require it, but do we actually know of any supported
important platforms where this happens?  If not, let's worry about the
more general fix on master, where we still have time to try various
solutions, and settle for a simpler and easier fix on emacs-27.

> And that specific workaround should not be needed anyway if we
> install the emacs-27 patch that I have most-recently suggested (or
> Pip Cet's very-similar recent patch), since this patch solves the
> problem in a more-general way that should help to prevent more bugs
> like this one.

But your proposal is also less efficient, isn't it?   If so, its more
general nature comes at a price.