https://bugs.exim.org/show_bug.cgi?id=2042
Philip Hazel <p...@hermes.cam.ac.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Philip Hazel <p...@hermes.cam.ac.uk> ---
Windows systems seem to default to very small system stacks (1 MB often, I'm
told - I am not a Windows user). On my Linux box, your pattern has no problem
until I screw the stack down to 1 MB and have a subject line several thousand
characters long. (That may be why regex101.com works. Stack usage seems to vary
wildly between different OS, different compilers, and different optimization
levels.) PCRE (both 8.xx and 10.xx) uses the stack for remembering backtracking
points (see the pcre2stack man page), but over the years this has caused quite
a lot of hassle. You can compile the library with
--disable-stack-for-recursion, and it then gets blocks on the heap, but this
can run a lot slower.
The good news is that I am shortly going to start work on integrating a
refactored version of pcre2_match() into the main code base (I'm just letting
10.23 settle down for a week or two). This new version does not use recursive
function calls (and hence the stack) for backtracking. Instead it uses a vector
of frames, starting with one on the stack that is just 10K long. This can
handle quite a few frames, but if it's too small, memory on the heap will be
used. Preliminary tests show this running no slower, and possibly a bit faster,
than the current implementation. But it will be around 6 months before there is
a released version containing this new code.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
