>> Your patch is increasing the size of the stack from 20 to 40.
That
>> seems to be enough in this case, but does anyone have any idea what
>> the real limit should be? The FSF emacs code seems to be entirely
>> different.
>
>> Stefan - any thoughts?
>
> The quoted email I got wasn't enough to fire my neurons, and I couldn't find
> the original thread on xemacs-beta either. Can someone point me to the
> original thread?
xemacs-beta are not updating currently:
Last update: Thu Mar 16 06:22:04 GMT 2006
I actually searched on Gmane instead, so it must have been some other
problem (or maybe Gmane is late as well?).
Here's is what I think is the relevant mail:
That shows me the patch which I gather is a workaround. I still don't know
what error is signalled when :-(
The attached patch solves it for me.
Index: regex.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/regex.c,v
retrieving revision 1.56
diff -u -u -b -r1.56 regex.c
--- regex.c 2005/03/09 04:59:31 1.56
+++ regex.c 2006/03/17 13:31:33
@@ -1622,7 +1622,7 @@
/* We used to use (num_regs - 1), which is the number of registers
this regexp will save; but that was changed to 5
to avoid stack overflow for a regexp with lots of parens. */
-#define MAX_FAILURE_ITEMS (5 * NUM_REG_ITEMS + NUM_NONREG_ITEMS)
+#define MAX_FAILURE_ITEMS (5 * (NUM_REG_ITEMS + NUM_NONREG_ITEMS))
/* We actually push this many items. */
#define NUM_FAILURE_ITEMS \
Hmm... I removed this whole MAX_FAILURE_ITEMS in Emacs-21's regex.c and
I can't quite remember what it was used for. IIRC it is linked to the way
the old code tried to restore "registers" (used to keep track of subgroups
in a match) when backtracking, but the code was fundamentally flawed which
lead to a pile of hacks-over-hacks to cover the various holes.
I thought Ben Wing had merged into XEmacs the changes I made to Emacs's
regex.c, but apparently not.
I suppose the best way to solve this problem is to work around it in
grep.el.
Stefan