Be less eager to define MATCH_MAY_ALLOCATE.
authorRichard Stallman <rms@gnu.org>
Tue, 5 Jul 1994 07:25:05 +0000 (07:25 +0000)
committerRichard Stallman <rms@gnu.org>
Tue, 5 Jul 1994 07:25:05 +0000 (07:25 +0000)
regex.c

diff --git a/regex.c b/regex.c
index bd9ad6f6972e057e41dfe466831584d94979d998..0cfd4969982a62fef8985b78cf1f4d3147e66e8b 100644 (file)
--- a/regex.c
+++ b/regex.c
@@ -898,8 +898,8 @@ static const char *re_error_msg[] =
    ralloc heap) shift the data out from underneath the regexp
    routines.
 
-   Here's another reason to avoid allocation: Emacs insists on
-   processing input from X in a signal handler; processing X input may
+   Here's another reason to avoid allocation: Emacs 
+   processes input from X in a signal handler; processing X input may
    call malloc; if input arrives while a matching routine is calling
    malloc, then we're scrod.  But Emacs can't just block input while
    calling matching routines; then we don't notice interrupts when
@@ -910,8 +910,9 @@ static const char *re_error_msg[] =
 /* Normally, this is fine.  */
 #define MATCH_MAY_ALLOCATE
 
-/* But under some circumstances, it's not.  */
-#if defined (emacs) || (defined (REL_ALLOC) && defined (C_ALLOCA))
+/* The match routines may not allocate if (1) they would do it with malloc
+   and (2) it's not safe for htem to use malloc.  */
+#if (defined (C_ALLOCA) || defined (REGEX_MALLOC)) && (defined (emacs) || defined (REL_ALLOC))
 #undef MATCH_MAY_ALLOCATE
 #endif