Fix pcrepattern(3) documentation

pcre2-10.22-Fix-typos-in-documentation.patch

@@ -0,0 +1,59 @@
+From 21a37ed924de50cc36ff47b17a9711058bb5ab2e Mon Sep 17 00:00:00 2001
+From: ph10 <ph10@6239d852-aaf2-0410-a92c-79f79f948069>
+Date: Thu, 6 Oct 2016 17:44:39 +0000
+Subject: [PATCH] Fix typos in documentation.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+git-svn-id: svn://vcs.exim.org/pcre2/code/trunk@560 6239d852-aaf2-0410-a92c-79f79f948069
+
+Petr Písař: Ported to 10.22.
+
+Signed-off-by: Petr Písař <ppisar@redhat.com>
+---
+ doc/pcre2pattern.3 | 13 ++++++-------
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+diff --git a/doc/pcre2pattern.3 b/doc/pcre2pattern.3
+index 70ac14a..4516ffc 100644
+--- a/doc/pcre2pattern.3
++++ b/doc/pcre2pattern.3
+@@ -359,8 +359,7 @@ case letter, it is converted to upper case. Then bit 6 of the character (hex
+ 40) is inverted. Thus \ecA to \ecZ become hex 01 to hex 1A (A is 41, Z is 5A),
+ but \ec{ becomes hex 3B ({ is 7B), and \ec; becomes hex 7B (; is 3B). If the
+ code unit following \ec has a value less than 32 or greater than 126, a
+-compile-time error occurs. This locks out non-printable ASCII characters in all
+-modes.
++compile-time error occurs.
+ .P
+ When PCRE2 is compiled in EBCDIC mode, \ea, \ee, \ef, \en, \er, and \et
+ generate the appropriate EBCDIC code values. The \ec escape is processed
+@@ -369,19 +368,19 @@ that are allowed after \ec are A-Z, a-z, or one of @, [, \e, ], ^, _, or ?. Any
+ other character provokes a compile-time error. The sequence \e@ encodes
+ character code 0; the letters (in either case) encode characters 1-26 (hex 01
+ to hex 1A); [, \e, ], ^, and _ encode characters 27-31 (hex 1B to hex 1F), and
+-\e? becomes either 255 (hex FF) or 95 (hex 5F).
++\ec? becomes either 255 (hex FF) or 95 (hex 5F).
+ .P
+-Thus, apart from \e?, these escapes generate the same character code values as
++Thus, apart from \ec?, these escapes generate the same character code values as
+ they do in an ASCII environment, though the meanings of the values mostly
+-differ. For example, \eG always generates code value 7, which is BEL in ASCII
++differ. For example, \ecG always generates code value 7, which is BEL in ASCII
+ but DEL in EBCDIC.
+ .P
+-The sequence \e? generates DEL (127, hex 7F) in an ASCII environment, but
++The sequence \ec? generates DEL (127, hex 7F) in an ASCII environment, but
+ because 127 is not a control character in EBCDIC, Perl makes it generate the
+ APC character. Unfortunately, there are several variants of EBCDIC. In most of
+ them the APC character has the value 255 (hex FF), but in the one Perl calls
+ POSIX-BC its value is 95 (hex 5F). If certain other characters have POSIX-BC
+-values, PCRE2 makes \e? generate 95; otherwise it generates 255.
++values, PCRE2 makes \ec? generate 95; otherwise it generates 255.
+ .P
+ After \e0 up to two further octal digits are read. If there are fewer than two
+ digits, just those that are present are used. Thus the sequence \e0\ex\e015
+-- 
+2.7.4
+

pcre2-10.22-Missed-typo-fixed.patch

@@ -0,0 +1,36 @@
+From 509ecc74dcbbcfabc01f4d290c9cc8b62c921ac4 Mon Sep 17 00:00:00 2001
+From: ph10 <ph10@6239d852-aaf2-0410-a92c-79f79f948069>
+Date: Thu, 6 Oct 2016 17:48:24 +0000
+Subject: [PATCH] Missed typo fixed.
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+git-svn-id: svn://vcs.exim.org/pcre2/code/trunk@561 6239d852-aaf2-0410-a92c-79f79f948069
+Signed-off-by: Petr Písař <ppisar@redhat.com>
+---
+ doc/pcre2pattern.3 | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/doc/pcre2pattern.3 b/doc/pcre2pattern.3
+index 3cde744..f9d1f53 100644
+--- a/doc/pcre2pattern.3
++++ b/doc/pcre2pattern.3
+@@ -365,10 +365,10 @@ When PCRE2 is compiled in EBCDIC mode, \ea, \ee, \ef, \en, \er, and \et
+ generate the appropriate EBCDIC code values. The \ec escape is processed
+ as specified for Perl in the \fBperlebcdic\fP document. The only characters
+ that are allowed after \ec are A-Z, a-z, or one of @, [, \e, ], ^, _, or ?. Any
+-other character provokes a compile-time error. The sequence \e@ encodes
+-character code 0; the letters (in either case) encode characters 1-26 (hex 01
+-to hex 1A); [, \e, ], ^, and _ encode characters 27-31 (hex 1B to hex 1F), and
+-\ec? becomes either 255 (hex FF) or 95 (hex 5F).
++other character provokes a compile-time error. The sequence \ec@ encodes
++character code 0; after \ec the letters (in either case) encode characters 1-26
++(hex 01 to hex 1A); [, \e, ], ^, and _ encode characters 27-31 (hex 1B to hex
++1F), and \ec? becomes either 255 (hex FF) or 95 (hex 5F).
+ .P
+ Thus, apart from \ec?, these escapes generate the same character code values as
+ they do in an ASCII environment, though the meanings of the values mostly
+-- 
+2.7.4
+

pcre2.spec

@@ -30,6 +30,10 @@ Patch1:     pcre2-10.22-Fix-bug-that-caused-chars-255-not-to-be-matched-by-c.pat
 # Fix displaying a callout position in pcretest output with an escape sequence
 # greater than \x{ff}, in upstream after 10.22
 Patch2:     pcre2-10.22-Fix-callout-display-bug-in-pcre2test.patch
+# 1/2 Fix pcrepattern(3) documentation, un upstream after 10.22
+Patch3:     pcre2-10.22-Fix-typos-in-documentation.patch
+# 2/2 Fix pcrepattern(3) documentation, in upstream after 10.22
+Patch4:     pcre2-10.22-Missed-typo-fixed.patch
 # New libtool to get rid of RPATH and to use distribution autotools
 BuildRequires:  autoconf
 BuildRequires:  automake
@@ -109,6 +113,8 @@ Utilities demonstrating PCRE2 capabilities like pcre2grep or pcre2test.
 %patch0 -p1
 %patch1 -p1
 %patch2 -p1
+%patch3 -p1
+%patch4 -p1
 # Because of multilib patch
 libtoolize --copy --force
 autoreconf -vif
@@ -208,6 +214,7 @@ make %{?_smp_mflags} check VERBOSE=yes
 * Wed Oct 19 2016 Petr Pisar <ppisar@redhat.com> - 10.22-3
 - Fix displaying a callout position in pcretest output with an escape sequence
   greater than \x{ff}
+- Fix pcrepattern(3) documentation
 
 * Mon Aug 29 2016 Petr Pisar <ppisar@redhat.com> - 10.22-2
 - Fix matching characters above 255 when a negative character type was used