r661 | ph10 | 2011-08-21 11:00:54 +0200 (Ne, 21 srp 2011) | 2 lines Fix bug introduced by 8.13/37 concerning POSIX class recognition Change 37 of 8.13 broke patterns like [:a]...[b:] because it thought it had a POSIX class. After further experiments with Perl, which convinced me that Perl has bugs and confusions, a closing square bracket is no longer allowed in a POSIX name. Petr Pisar: Changelog entries removed, tests adjusted as upstream want to tune them after merging JIT code. Index: pcre_compile.c =================================================================== --- a/pcre_compile.c (revision 660) +++ b/pcre_compile.c (revision 661) @@ -2295,9 +2295,14 @@ A user pointed out that PCRE was rejecting [:a[:digit:]] whereas Perl was not. It seems that the appearance of a nested POSIX class supersedes an apparent external class. For example, [:a[:digit:]b:] matches "a", "b", ":", or -a digit. Also, unescaped square brackets may also appear as part of class -names. For example, [:a[:abc]b:] gives unknown class "[:abc]b:]"in Perl. +a digit. +In Perl, unescaped square brackets may also appear as part of class names. For +example, [:a[:abc]b:] gives unknown POSIX class "[:abc]b:]". However, for +[:a[:abc]b][b:] it gives unknown POSIX class "[:abc]b][b:]", which does not +seem right at all. PCRE does not allow closing square brackets in POSIX class +names. + Arguments: ptr pointer to the initial [ endptr where to return the end pointer @@ -2314,6 +2319,7 @@ { if (*ptr == CHAR_BACKSLASH && ptr[1] == CHAR_RIGHT_SQUARE_BRACKET) ptr++; + else if (*ptr == CHAR_RIGHT_SQUARE_BRACKET) return FALSE; else { if (*ptr == terminator && ptr[1] == CHAR_RIGHT_SQUARE_BRACKET) Index: testdata/testoutput2 =================================================================== --- a/testdata/testoutput2 (revision 661) +++ b/testdata/testoutput2 (working copy) @@ -12137,7 +12137,6 @@ ------------------------------------------------------------------ /[:a[:abc]b:]/ -Failed: unknown POSIX class name at offset 5 /((?2))((?1))/ abc