3 messages, 3 authors, 2021-11-16 · open the first message on its own page
From: Andreas Schwab <hidden>
Date: 2021-11-16 00:18:07
This breaks 'PCRE v2: grep ASCII from invalid UTF-8 data'. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-11-15 23:44:32
On Mon, Nov 15 2021, Andreas Schwab wrote:
This breaks 'PCRE v2: grep ASCII from invalid UTF-8 data'.
What PCREv2 version are you using? I wonder if it's got to do with the 10.36 boundary, as noted in 95ca1f987ed (grep/pcre2: better support invalid UTF-8 haystacks, 2021-01-24). One of the two tests matching your description tests for that bug. I can't remember much of the details of the bug, and it seems PCREv2's bug tracker went private, or at least I can't view https://bugs.exim.org/show_bug.cgi?id=2642 anymore.
From: Carlo Arenas <hidden>
Date: 2021-11-16 05:12:29
I can't remember much of the details of the bug, and it seems PCREv2's bug tracker went private, or at least I can't view https://bugs.exim.org/show_bug.cgi?id=2642 anymore.
It was shutdown; all new development is now done in github[1], old closed bugs were not migrated over though but the fix is pretty straight forward if it needs backporting[2] I would have expected the less risky change from René[3] to be released though, but might be a good opportunity to take a deeper look at the underlying problem and also have a likely solution to both the regression and the original bug. Carlo [1] https://github.com/PhilipHazel/pcre2 [2] https://github.com/PhilipHazel/pcre2/commit/f8cbb1f58df05f175a6898f35dc18e26be6362d0 [3] https://lore.kernel.org/git/0ea73e7a-6d43-e223-ab2e-24c684102856@web.de/