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 62a102e384510936a6ece9ee1d4656e6c1118a7a..7cbd2966839aae22b9d16d007a2d85e3fa891e5c 100644 (file)
--- 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