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

> From: Paul Eggert <address@hidden>
> Date: Sat, 9 Jun 2018 21:03:25 -0700
> Cc: address@hidden
> /* 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

OTOH, maybe I do agree, as long as "blindly" is an essential part of
that rule ;-)

reply via email to

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