emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: re-search-forward ... nil t) results in error instead of returningni


From: Drew Adams
Subject: RE: re-search-forward ... nil t) results in error instead of returningnil
Date: Sat, 20 Nov 2004 10:56:31 -0800

I just tried the same (non-greedy) regexp again in a virgin emacs (same
version - I don't have CVS Emacs, but this version is pretty close), and it
succeeded!

Then I repeated the command and it failed with stack overflow. Repeating
subsequently gave stack overflow.

I quit Emacs, started it up, and tried again. Stack overflow right away.
Repeated the command and it succeeded! Repeated again: stack overflow.
Subsequent repetitions: stack overflow. Quit Emacs and repeated - stack
overflow every time. Quit and tried again - same thing: overflow.

I also tried the normal, greedy version of the regexp - with the same result
(overflow). IOW, this is a regexp that succeeds consistently in Emacs 20 and
fails most of the time in Emacs 21. That looks like a bug, to me.

You say that the non-nil "no-fail" arg to re-search-forward is not supposed
to catch stack overflows and such. If so, then the doc should, I think, be
changed. Currently, the doc suggests (to me, anyway) that the "no-fail" arg
causes the function to return nil in case of _failure_ (and it speaks
specifically of _error_) - not just failure to find a match:

  "Optional third argument, if t, means if fail just return nil (no error).
  If not nil and not t, move to limit of search and return nil."

Similarly, the text you quote also suggests (to me) that the argument
protects against failure generally, not just a `search-failed' error.

So, wrt the third, "no-fail" arg, I think either it is not doing its job
correctly (if the function is supposed to return nil in case of any error)
or there is a doc bug.

You mention the REPEAT arg, but I don't believe that that has anything to do
with this - the REPEAT arg was nil in this test.

You mention that excessively complex regexps can cause stack overflow. This
regexp should not be "excessively complex".  It is the regexp that we might
use (21.4?) for the fontification of strings and quoted names in Info (patch
sent - waiting for papers).

And the normal, greedy version fails too, though it succeeds consistently in
Emacs 20. The regexp works fine throughout Info, but apparently fails (most
of the time) on the Key Index node. I tested it previously on this node, in
particular, and I didn't notice the problem, but perhaps I got lucky then.

For the new Info patch, we can always wrap the seach in a condition-case,
but I suspect it would be better to fix this bug - especially since it does
not manifest itself all the time: the regexp (greedy or non-greedy) does
succeed some of the time.

BTW, can I change the stack size from Lisp? I know that I can change
`max-lisp-eval-depth' and `max-specpdl-size', and that increasing the former
can lead to stack overflows, but is there a way to increase the stack size
from Lisp? I suspect not, since the stack is presumably C code.

Thanks,

   Drew

    -----Original Message-----From: Luc Teirlinck
       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?






reply via email to

[Prev in Thread] Current Thread [Next in Thread]