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

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 9 Jun 2018 21:03:25 -0700
> Cc: 31750@debbugs.gnu.org
> 
> /* 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.  */

I'm not sure I agree with the last part, at least not in such
categorical terms.  E.g., w32notify.c does exactly what the above says
not to do, and AFAICT is a very good candidate for using mint_ptr
objects.

OTOH, maybe I do agree, as long as "blindly" is an essential part of
that rule ;-)