From 7648c125dfdd0232362c35c2898bbe355c874dc1 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Wed, 26 Jun 2019 18:02:26 +0300 Subject: [PATCH] Clarify a subtle issue in the Internals chapter of lispref * doc/lispref/internals.texi (Writing Emacs Primitives): Clarify the issue with relocation of buffer or string text as side effect of Lisp evaluation. (Bug#36392) --- doc/lispref/internals.texi | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi index 62a102e3845..7cbd2966839 100644 --- a/doc/lispref/internals.texi +++ b/doc/lispref/internals.texi @@ -825,10 +825,14 @@ the type explicitly using a suitable predicate (@pxref{Type Predicates}). @code{args} refers to objects controlled by Emacs's stack-marking garbage collector. Although the garbage collector does not reclaim objects reachable from C @code{Lisp_Object} stack variables, it may -move non-object components of an object, such as string contents; so -functions that access non-object components must take care to refetch -their addresses after performing Lisp evaluation. Lisp evaluation can -occur via calls to @code{eval_sub} or @code{Feval}, either directly or +move some of the components of an object, such as the contents of a +string or the text of a buffer. Therefore, functions that access +these components must take care to refetch their addresses after +performing Lisp evaluation. This means that instead of keeping C +pointers to string contents or buffer text, the code should keep the +buffer or string position, and recompute the C pointer from the +position after performing Lisp evaluation. Lisp evaluation can occur +via calls to @code{eval_sub} or @code{Feval}, either directly or indirectly. @cindex @code{maybe_quit}, use in Lisp primitives -- 2.39.2