[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] emacs-25 223b3f0: Improve regex to not trigger stack o
From: |
Tassilo Horn |
Subject: |
Re: [Emacs-diffs] emacs-25 223b3f0: Improve regex to not trigger stack overflow |
Date: |
Mon, 14 Dec 2015 18:31:25 +0100 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
Hi Stefan,
>> - "\\[[^][]*\\<label[[:space:]]*=[[:space:]]*{?\\(?1:[^],}]+\\)}?")
>> +
>> "\\[[^][]\\{0,2000\\}\\<label[[:space:]]*=[[:space:]]*{?\\(?1:[^],}]+\\)}?")
>
> BTW, if you don't like the arbitrary limit, you can probably "fix" the
> problem (or at least reduce the stack usage enough that it doesn't
> show up any more in practice) by replacing "[^][]*" with something
> like "\\(?:[^[],]*,\\)*[ \t]*".
Oh, indeed, that also works (except that it should be
"\\(?:[^][,]*,\\)*[ \t]*", i.e. switched ][ order in the negative
character class). I tested it with a very large file with a [ at the
very beginning which is never closed again, and still the stack didn't
overflow. That's obviously better than a random (although practically
probably large enough) limit, and I'm using that now.
> The difference is that in "[^[],]*,", the "*" repetition will be done
> without any need to record state for eventual backtracking (because
> the "," is mutually exclusive with the "[^[],]", and the regexp
> matcher includes a special optimization for that case since it's
> common and very useful).
Thanks for the explanation. I'll try to keep it at the back of my
mind. :-)
Bye,
Tassilo