bug#31750: simplify and tune Emacs stack-related allocation

[Paul Eggert]

Noam Postavsky wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
>
> > Subject: [PATCH 01/10] New mint_ptr representation for C pointers
> >
> > * src/lisp.h (make_mint_ptr, mint_ptrp, xmint_pointer): New functions.
>
> > Use mint pointers instead of merely save pointers.
>
> I think it would be helpful to add a brief summary of the tradeoffs
> between save pointers and mint pointers to the commit message.

Thanks for looking at it. Here's a quick attempt at a summary comment for 
make_mint_ptr. This wording compares mint_ptr values to Lisp_User_Ptr values, 
not to save pointers, in order simplify the later patch that removes save pointers.

/* A mint_ptr object OBJ represents a C-language pointer P efficiently.
   Preferably (and typically), OBJ is a Lisp integer I such that
   XINTPTR (I) == P, as this represents P within a single Lisp value
   without requiring any auxiliary memory.  However, if P would be
   damaged by being tagged as an integer and then untagged via
   XINTPTR, then OBJ is a Lisp_Save_Value with pointer component P.

   mint_ptr objects are efficiency hacks that are intended for use
   only within C code.  C code should never blindly accept a mint_ptr
   object from Lisp code, as that would allow Lisp code to coin
   pointers from integers and could lead to crashes.  A C pointer that
   needs to be packaged into a Lisp-visible object can be made part of
   a Lisp_Misc type instead; see Lisp_User_Ptr for an example.  */