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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
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 09:12:33 -0700

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.

Previous Next

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