Re: stack overflow with (re-search-forward "..." nil t)

Re: stack overflow with (re-search-forward "..." nil t)

[rgb]

> 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.

RE: stack overflow with (re-search-forward "..." nil t)

[Drew Adams]

    > 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".

Re: stack overflow with (re-search-forward "..." nil t)

[Richard M. Stallman]

    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.

stack overflow with (re-search-forward "..." nil t)

[Drew Adams]

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?