|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |