https://bugs.exim.org/show_bug.cgi?id=1732
Bug ID: 1732
Summary: Negated classes containing negated POSIX classes
matches incorrectly
Product: PCRE
Version: 8.38
Hardware: x86
OS: All
Status: NEW
Severity: bug
Priority: medium
Component: Code
Assignee: ph10@???
Reporter: justin.viiret@???
CC: pcre-dev@???
(Firstly, many thanks for fixing the previous round of POSIX class issues in
8.38; after the update, I think I'm down to the last issue or two to pop out of
our testing tools in this area now!)
Following on from bug #1719 ("Class containing negated POSIX classes with other
classes match incorrectly"), I think that there is a bug affecting character
classes containing negated POSIX classes that do not have UCP replacements
(e.g. [:^ascii:], [:^cntrl:]) that (a) are themselves negated and (b) contain
another class mnemonic matching codepoints greater than 255.
Here is an example in PCRE test data format:
--------
/[^[:^ascii:]\d]/8W
a
~
0
\a
\x{7f}
\x{389}
\x{20ac}
--------
I think that this pattern should match characters in [:ascii:] that are not
digits.
I get the following output from pcretest in PCRE 8.38:
--------
PCRE version 8.38 2015-11-23
re> data> 0: a
data> 0: ~
data> No match
data> 0: \x{07}
data> 0: \x{7f}
data> 0: \x{389}
data> 0: \x{20ac}
--------
The results look correct for matches in the normal ASCII range. However, PCRE
8.38 produces a match for the last two inputs above (greek letter omega, euro
currency symbol). Perl 5.020002 (using perltest) does not produce these two
matches.
PCRE2 10.20 produces the same behaviour.
--
You are receiving this mail because:
You are on the CC list for the bug.
