From: Eli Zaretskii Date: Wed, 26 Jun 2019 15:02:26 +0000 (+0300) Subject: Clarify a subtle issue in the Internals chapter of lispref X-Git-Tag: emacs-26.3~66 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=7648c12;p=emacs.git 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) --- 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