https://bugs.exim.org/show_bug.cgi?id=2315
--- Comment #3 from Rich Siegel <siegel@???> ---
I can provide both, although it will take some time to extract my PCRE1 code
into a testable form. I will do that ASAP.
Was there some build configuration in PCRE1 which allowed "\r" and "\n" to be
treated interchangeably when compiling a pattern?
It's been long enough since I adopted PCRE 8 that I don't recall at this
remove, and I'm wondering if I failed to set something appropriately in PCRE2.
(Using ccmake and reviewing the settings didn't ring any bells.)
Given this pattern: .+\r
...the behavior with PCRE1 was that searching for the pattern would match an
entire line in the editor, including the trailing newline. (Our internal
representation is UTF-16 and LF for line breaks, but a long time ago, we used
CR for line breaks internally and so customers have a lot of old patterns that
they wrote using "\r".)
When using PCRE2, this fails to match. It's consistent with your description,
but a behavior difference from PCRE1.
This pattern works correctly using both PCRE1 and PCRE2: .+\n
If you have access to a Mac running a reasonably recent version of the OS, I
will be happy to make builds of the application available, in case that would
be useful. I can also provide a Zip of both my PCRE1 and PCRE2 working copies.
--
You are receiving this mail because:
You are on the CC list for the bug.
