https://bugs.exim.org/show_bug.cgi?id=2769
--- Comment #9 from Carlo Marcelo Arenas Belón ---
(In reply to Thomas Tempelmann from comment #8)
> > start with 10.38
>
> That's not released yet, as far as I can tell.
my bad; off by one error, somehow I thought you meant you were not in the
https://bugs.exim.org/show_bug.cgi?id=2769
--- Comment #8 from Thomas Tempelmann ---
> start with 10.38
That's not released yet, as far as I can tell.
> not being able to compile might be the expected behaviour though, as macos
> 11 arm64 is the minimum supported version of the OS and the API
https://bugs.exim.org/show_bug.cgi?id=2769
--- Comment #7 from Carlo Marcelo Arenas Belón ---
(In reply to Thomas Tempelmann from comment #6)
> Note that I added the 111 patch to the released version 10.37.
backporting this to 10.37 is likely to also require #90 as you pointed out as
well as
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #4 from firas ---
If you check the links I provided, both implementations (that of regex101 and
multiple versions of PHP), they both result in infinite loops.
I haven't checked how pcre2test breaks out of it, but clearly there is a
https://bugs.exim.org/show_bug.cgi?id=2769
--- Comment #6 from Thomas Tempelmann ---
Note that I added the 111 patch to the released version 10.37.
I wonder if I also need to apply this patch first:
(https://github.com/zherczeg/sljit/pull/90/files)
--
You are receiving this mail because:
You
https://bugs.exim.org/show_bug.cgi?id=2769
Thomas Tempelmann changed:
What|Removed |Added
CC||tempelm...@gmail.com
--- Comment #5 from
https://bugs.exim.org/show_bug.cgi?id=2793
Bug ID: 2793
Summary: Case insensitive search gets exponentially slower with
larger buffers and a specific text file
Product: PCRE
Version: 10.37 (PCRE2)
Hardware: x86-64
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #3 from Philip Hazel ---
Hmm. Have I missed something? I tried the pattern you quoted and didn't get an
infinite loop (this is pcre2test):
PCRE2 version 10.37 2021-05-26
/(?<=(<|>|=)\K=)/
50||(7<=Dex&&8>=MHP)==2
0: =
1: <
Which is what I
We had had a similar discussion a few years back, where I stated that a certain
usage is wrong and you answered that changing PCRE will break a few patterns
who may rely on the wrong usage. In the end you've adopted my view after I'd
asked to allow me an exception in the z/OS EBCDIC specific
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #2 from firas ---
Thanks for the reply.
I stumbled upon this due to the following regex by a user:
https://regex101.com/r/7PPxPD/1/
This results in an infinite loop, even in other implementations such as PHP:
https://3v4l.org/F4NhG
It
https://bugs.exim.org/show_bug.cgi?id=2792
--- Comment #1 from Philip Hazel ---
Perl used to allow \K in lookarounds. I am aware that it has changed, and this
is documented in pcre2pattern:
"Perl used to document that the use of \K within lookaround assertions is "not
well defined", but from
https://bugs.exim.org/show_bug.cgi?id=2792
Bug ID: 2792
Summary: \K should not be allowed in lookarounds
Product: PCRE
Version: 10.36 (PCRE2)
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
12 matches
Mail list logo
