https://bugs.exim.org/show_bug.cgi?id=2315
--- Comment #3 from Rich Siegel <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
