[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31750: simplify and tune Emacs stack-related allocation
From: |
Eli Zaretskii |
Subject: |
bug#31750: simplify and tune Emacs stack-related allocation |
Date: |
Sun, 10 Jun 2018 18:07:23 +0300 |
> 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 ;-)