[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: bug#31750: simplify and tune Emacs stack-related allocation
Date: Sat, 9 Jun 2018 21:03:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

Noam Postavsky wrote:
Paul Eggert <address@hidden> 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.  */

reply via email to

[Prev in Thread] Current Thread [Next in Thread]