From d5ec18c66bdefb492826eab0d60e818d5bac7238 Mon Sep 17 00:00:00 2001 From: Stefan Monnier Date: Sat, 18 Apr 2020 23:01:43 -0400 Subject: * src/regex-emacs.c (re_match_2_internal): Rework comment in last change Explain why we don't need to worry about Lisp modifying the buffer. * src/syntax.c (parse_sexp_propertize): Fix name in error message. --- src/regex-emacs.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'src/regex-emacs.c') diff --git a/src/regex-emacs.c b/src/regex-emacs.c index f456b495397..5e23fc94e4f 100644 --- a/src/regex-emacs.c +++ b/src/regex-emacs.c @@ -3959,9 +3959,11 @@ re_match_2_internal (struct re_pattern_buffer *bufp, /* Prevent shrinking and relocation of buffer text if GC happens while we are inside this function. The calls to - UPDATE_SYNTAX_TABLE_* macros can trigger GC if they call Lisp, - and we have C pointers to buffer text that must not become - invalid as result of GC. */ + UPDATE_SYNTAX_TABLE_* macros can call Lisp (via + `internal--syntax-propertize`); these calls are careful to defend against + buffer modifications, but even with no modifications, the buffer text may + be relocated during GC by `compact_buffer` which would invalidate + our C pointers to buffer text. */ if (!current_buffer->text->inhibit_shrinking) { record_unwind_protect_ptr (unwind_re_match, current_buffer); -- cgit v1.2.1