[pcre-dev] [Bug 2315] PCRE2_NEWLINE_ANYCRLF appears to be n…

Top Page

Reply to this message
Author: admin
Date:  
To: pcre-dev
Subject: [pcre-dev] [Bug 2315] PCRE2_NEWLINE_ANYCRLF appears to be nonfunctional
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.