[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: Sun, 10 Jun 2018 09:12:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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

Yes, the "blindly" is essential. It's OK to use xmint_ptr on any mint_ptr, so long as you don't blindly trust the result to be a valid C pointer of the kind that you want; that is, you have to know that your C code created the mint_ptr in question and that no Lisp code can have replaced the mint_ptr with some other object (perhaps also a mint_ptr). This is like XSAVE_POINTER, where you also have to know that Lisp code has not replaced the Lisp_Save_Value object with some other object (perhaps also of type Lisp_Save_Value and with a pointer payload).

The main difference is that Lisp code can easily coin a mint_ptr (simply by using a fixnum) whereas it can't easily coin a Lisp_Save_Value, so there's less runtime checking to catch bugs in the C code. However, if two or more Lisp_Save_Value objects are exposed to Lisp code then the Lisp code can pass one where the other is expected and this can cause the same sort of crash as passing a fixnum where a mint_ptr is expected, so introducing mint_ptr doesn't make things that much more dangerous in principle than they were before.

reply via email to

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