Fix pcrepattern(3) documentation

pcre-8.39-Fix-typos-in-documentation.patch

@@ -0,0 +1,52 @@
+From c53d4af2465bf11a8aefceb67bf7f7ae19b08ac5 Mon Sep 17 00:00:00 2001
+From: ph10 <ph10@2f5784b3-3f2a-0410-8824-cb99058d5e15>
+Date: Thu, 6 Oct 2016 17:49:48 +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/pcre/code/trunk@1666 2f5784b3-3f2a-0410-8824-cb99058d5e15
+Signed-off-by: Petr Písař <ppisar@redhat.com>
+---
+ doc/pcrepattern.3 | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/doc/pcrepattern.3 b/doc/pcrepattern.3
+index 3b8c639..952451f 100644
+--- a/doc/pcrepattern.3
++++ b/doc/pcrepattern.3
+@@ -336,22 +336,22 @@ When PCRE 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
+-\e? 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 \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, PCRE makes \e? generate 95; otherwise it generates 255.
++values, PCRE 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
+

pcre.spec

@@ -48,6 +48,8 @@ Patch4:     pcre-8.39-Fix-character-class-bug-when-a-Unicode-property-was-.patch
 # Fix displaying position in pcretest callout with an escape sequence greater
 # than \x{ff}, in upstream after 8.39
 Patch5:     pcre-8.39-Fix-pcretest-callout-display-bug.patch
+# Fix pcrepattern(3) documentation, in upstream after 8.39
+Patch6:     pcre-8.39-Fix-typos-in-documentation.patch
 BuildRequires:  readline-devel
 BuildRequires:  autoconf
 BuildRequires:  automake
@@ -141,6 +143,7 @@ Utilities demonstrating PCRE capabilities like pcregrep or pcretest.
 %patch3 -p1
 %patch4 -p1
 %patch5 -p1
+%patch6 -p1
 # Because of rpath patch
 libtoolize --copy --force
 autoreconf -vif
@@ -240,6 +243,7 @@ make %{?_smp_mflags} check VERBOSE=yes
 * Fri Oct 14 2016 Petr Pisar <ppisar@redhat.com> - 8.39-4
 - Fix displaying position in pcretest callout with an escape sequence greater
   than \x{ff}
+- Fix pcrepattern(3) documentation
 
 * Tue Aug 30 2016 Petr Pisar <ppisar@redhat.com> - 8.39-3
 - Fix register overwite in JIT when SSE2 acceleration is enabled