Re: re-search-forward ... nil t) results in error instead of returning nil

[Luc Teirlinck]

Drew Adams wrote:

   emacs -q

   Go to node Key Index of Emacs Info manual. Execute this:

   (re-search-forward "\"\\(?:[^\\\"]\\|\\\\\\(?:.\\|[\n]\\)\\)*\"\\|`[^']+'"
   nil t)

   You get this error:

Does not happen for me.  A match is found.  But I guess all that this
means is that I have different settings regarding maximum stack size.

   Maybe I misunderstand the meaning of the third arg. I thought that if
   non-nil any error would be caught and nil would be returned, instead
   of raising an error. Is this a bug or is my understanding wrong?

>From `(elisp)Regexp Search':

     If REPEAT is supplied (it must be a positive number), then the
     search is repeated that many times (each time starting at the end
     of the previous time's match).  If all these successive searches
     succeed, the function succeeds, moving point and returning its new
     value.  Otherwise the function fails.

     What happens when the function fails depends on the value of
     NOERROR.  If NOERROR is `nil', a `search-failed' error is
     signaled.  If NOERROR is `t', `re-search-forward' does nothing and
     returns `nil'.  If NOERROR is neither `nil' nor `t', then
     `re-search-forward' moves point to LIMIT (or the end of the
     accessible portion of the buffer) and returns `nil'.

Note that REPEAT determines what happens if the function `fails',
which is defined above as meaning that not enough matches were found.
In a certain sense NOERROR "catches" `search-failed' errors (although
not literally).  It does not try to catch other errors, like
invalid regexps, wrong type argument, stack overflow or whatever.

   Is there perhaps also a bug in the regexp matcher, which makes this
   overflow?

I believe I remember from earlier discussions that it is a known
limitation that excessively complex regexps can cause stack overflow.
Somebody can correct me if I am wrong.  If so, maybe this should be
pointed out in both the Emacs and Elisp manuals.  I could not find any
mention of it.

   BTW (probably unrelated to bug): In Emacs 20, doing the same thing,
   but using this similar regexp (no non-greedy matching), succeeds, with
   no Stack overflow error:
   "\"\\([^\\\"]\\|\\\\\\(.\\|[\n]\\)\\)*\"\\|`[^']+'"

Does the above regexp (without non-greedy matching) cause stack
overfow for you in current CVS?

Sincerely,

Luc.