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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: npostavs <at> gmail.com, 31750 <at> debbugs.gnu.org
Subject: Re: bug#31750: simplify and tune Emacs stack-related allocation
Date: Sun, 10 Jun 2018 18:07:23 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 9 Jun 2018 21:03:25 -0700
> Cc: 31750 <at> 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 ;-)

Previous Next

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