* stack overflow with (re-search-forward "..." nil t)
@ 2005-07-05 3:31 Drew Adams
0 siblings, 0 replies; 4+ messages in thread
From: Drew Adams @ 2005-07-05 3:31 UTC (permalink / raw)
I don't understand the `noerror' argument to re-search-forward, when it is
`t'. For some kinds of errors it works, but I still get stack-overflow
errors signaled, instead of the function returning nil. The doc string and
Elisp manual simply say that `noerror'=t returns nil in case of error.
As a workaround, I'm wrapping the call in condition-case, and that works
fine:
(condition-case nil
(re-search-forward hairy-regexp nil t)
(error nil))
But I would like to understand the stack-overflow behavior. Why doesn't
re-search-forward itself use the equivalent of a condition-case wrapper to
ensure that nil is returned in case of an error? If that can't be done
easily in C, why isn't the function defined using a Lisp wrapper that does a
condition-case?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: stack overflow with (re-search-forward "..." nil t)
[not found] <mailman.2170.1120536345.2857.help-gnu-emacs@gnu.org>
@ 2005-07-05 21:21 ` rgb
2005-07-05 21:57 ` Drew Adams
0 siblings, 1 reply; 4+ messages in thread
From: rgb @ 2005-07-05 21:21 UTC (permalink / raw)
> I don't understand the `noerror' argument to re-search-forward, when it is
> `t'. For some kinds of errors it works, but I still get stack-overflow
> errors signaled, instead of the function returning nil. The doc string and
> Elisp manual simply say that `noerror'=t returns nil in case of error.
If you expect it should return nil even in the case of a bad argument,
I don't think that was the intention. In fact I'd be complaining if it
did work that way. A wrapper is definitely necessary to get that level
of safety.
Having said that, it sounds like a bug. Although your wrapper might
appear to work I suspect it just masks the true problem. That being
either your regexp is bad and the error isn't being detected/reported
in a useful way, or the regexp is OK but your combination of regexp
tokens and buffer data trigger a bug that ultimately crashes the
search. Either way I don't think a wrapper is the answer.
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: stack overflow with (re-search-forward "..." nil t)
2005-07-05 21:21 ` stack overflow with (re-search-forward "..." nil t) rgb
@ 2005-07-05 21:57 ` Drew Adams
2005-07-06 22:27 ` Richard M. Stallman
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2005-07-05 21:57 UTC (permalink / raw)
Cc: Emacs-Pretest-Bug
> I don't understand the `noerror' argument to
re-search-forward, when it is
> `t'. For some kinds of errors it works, but I still get stack-overflow
> errors signaled, instead of the function returning nil. The
doc string and
> Elisp manual simply say that `noerror'=t returns nil in case of error.
If you expect it should return nil even in the case of a bad argument,
I don't think that was the intention. In fact I'd be complaining if it
did work that way. A wrapper is definitely necessary to get that level
of safety.
I realize now that it is the doc (in particular, Info) that is not clear
enough (for me). It should clearly state that it returns nil (for NOERROR=t)
when a match is not found, instead of saying that it does so when the
"function fails".
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: stack overflow with (re-search-forward "..." nil t)
2005-07-05 21:57 ` Drew Adams
@ 2005-07-06 22:27 ` Richard M. Stallman
0 siblings, 0 replies; 4+ messages in thread
From: Richard M. Stallman @ 2005-07-06 22:27 UTC (permalink / raw)
Cc: emacs-pretest-bug, help-gnu-emacs
I realize now that it is the doc (in particular, Info) that is not clear
enough (for me). It should clearly state that it returns nil (for NOERROR=t)
when a match is not found, instead of saying that it does so when the
"function fails".
I rewrote that part of the Lisp Manual to be clearer. Thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-07-06 22:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.2170.1120536345.2857.help-gnu-emacs@gnu.org>
2005-07-05 21:21 ` stack overflow with (re-search-forward "..." nil t) rgb
2005-07-05 21:57 ` Drew Adams
2005-07-06 22:27 ` Richard M. Stallman
2005-07-05 3:31 Drew Adams
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).