Fix parsing named class in expression

pcre-8.13-named_class_tokenizer.patch

@@ -0,0 +1,54 @@
+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

pcre.spec

@@ -1,6 +1,6 @@
 Name: pcre
 Version: 8.13
-Release: 2%{?dist}
+Release: 3%{?dist}
 Summary: Perl-compatible regular expression library
 Group: System Environment/Libraries
 License: BSD
@@ -9,6 +9,8 @@ Source: ftp://ftp.csx.cam.ac.uk/pub/software/programming/%{name}/%{name}-%{versi
 Patch0: pcre-8.10-multilib.patch
 # Refused by upstream, bug #675477
 Patch1: pcre-8.12-refused_spelling_terminated.patch
+# Upstream bug #1136 fixed after 8.13, rhbz #732368
+Patch2: pcre-8.13-named_class_tokenizer.patch
 BuildRequires: readline-devel
 # New libtool to get rid of rpath
 BuildRequires: autoconf, automake, libtool
@@ -49,6 +51,7 @@ Utilities demonstrating PCRE capabilities like pcregrep or pcretest.
 %patch0 -p1 -b .multilib
 libtoolize --copy --force && autoreconf
 %patch1 -p1 -b .terminated_typos
+%patch2 -p1 -b .named_class_tokenizer
 # One contributor's name is non-UTF-8
 for F in ChangeLog; do
     iconv -f latin1 -t utf8 "$F" >"${F}.utf8"
@@ -110,6 +113,9 @@ make check
 %{_mandir}/man1/pcretest.*
 
 %changelog
+* Mon Aug 22 2011 Petr Pisar <ppisar@redhat.com> - 8.13-3
+- Fix parsing named class in expression (bug #732368)
+
 * Thu Aug 18 2011 Petr Pisar <ppisar@redhat.com> - 8.13-2
 - Separate utilities from libraries
 - Move pcre-config(1) manual to pcre-devel sub-package