all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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 ` 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 --
2005-07-05  3:31 stack overflow with (re-search-forward "..." nil t) Drew Adams
     [not found] <mailman.2170.1120536345.2857.help-gnu-emacs@gnu.org>
2005-07-05 21:21 ` rgb
2005-07-05 21:57   ` Drew Adams
2005-07-06 22:27     ` Richard M. Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.