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

From: Paul Eggert <[email-masked]>
Date: Sat, 9 Jun 2018 21:03:25 -0700

Noam Postavsky wrote:
> Paul Eggert <[email-masked]> 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.  */