GNU bug report logs - #31750
simplify and tune Emacs stack-related allocation

Previous Next

Full log

Message #19 received at 31750 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31750 <at> debbugs.gnu.org
Subject: Re: bug#31750: simplify and tune Emacs stack-related allocation
Date: Sat, 9 Jun 2018 21:03:25 -0700

Noam Postavsky wrote:
> Paul Eggert <eggert <at> 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.  */

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.