Re: nnmail-split-header-length-limit is EVIL!

[Dale Hagglund <rdh@best.com>]

Peter Seibel <peter@javamonkey.com> writes:

> >>>>> "Dale" == Dale Hagglund <rdh@best.com> writes:
> 
>     Dale> I haven't seen any examples of complete regular
>     Dale> expressions that cause the problems we're talking about
>     Dale> here . . . .  Do we have any known regexp/string pairs
>     Dale> that deonstrate the problem?
> 
> Try eval'ing the expression below with the data line below it. It'll
> run quickly as is. Then add a's on the end of one or two at a time and
> watch it slow down.

> (search-forward-regexp "\\(.*\\)*x")
> 
> xaaaaaa
> 
> [A good description of the exponential backracking in the previous
> regexp and a pointer to Friedl's _Mastering Regular Expressions_
> deleted. --rdh] 

Umm, I've read Friedl's book (I agree it's excellent), and I already
understand the basic reason regexps show exponential time behaviour.

I guess I wasn't precise enough.  I was asking for known regexps from
gnus split processing and corresponding header lines that show
exponential behaviour, not a generic example that demonstrates how it
can happen on contrived input.

(I have no problems with your example as such; it nicely demonstrates
how easily exponential matching time can arise.  But, I'd like to see
a regexp/string pair with this problem that shows up in real use of
gnus.)

Dale.