glib2 3.1.0-x86-mingw32 → 3.1.1-x86-mingw32

data/vendor/local/lib/libpcre.la

@@ -25,7 +25,7 @@ weak_library_names=''
 # Version information for libpcre.
 current=3
 age=2
-revision=6
+revision=8
 
 # Is this an already installed library?
 installed=yes

data/vendor/local/lib/libpcreposix.la

@@ -25,7 +25,7 @@ weak_library_names=''
 # Version information for libpcreposix.
 current=0
 age=0
-revision=3
+revision=4
 
 # Is this an already installed library?
 installed=yes

data/vendor/local/lib/pkgconfig/libpcre.pc

@@ -7,7 +7,7 @@ includedir=${prefix}/include
 
 Name: libpcre
 Description: PCRE - Perl compatible regular expressions C library with 8 bit character support
-Version: 8.38
+Version: 8.40
 Libs: -L${libdir} -lpcre
 Libs.private:  
 Cflags: -I${includedir} 

data/vendor/local/lib/pkgconfig/libpcrecpp.pc

@@ -7,6 +7,6 @@ includedir=${prefix}/include
 
 Name: libpcrecpp
 Description: PCRECPP - C++ wrapper for PCRE
-Version: 8.38
+Version: 8.40
 Libs: -L${libdir} -lpcre -lpcrecpp
 Cflags: -I${includedir} 

data/vendor/local/lib/pkgconfig/libpcreposix.pc

@@ -7,7 +7,7 @@ includedir=${prefix}/include
 
 Name: libpcreposix
 Description: PCREPosix - Posix compatible interface to libpcre
-Version: 8.38
+Version: 8.40
 Libs: -L${libdir} -lpcreposix
 Cflags: -I${includedir} 
 Requires.private: libpcre

data/vendor/local/share/doc/pcre/AUTHORS

@@ -8,7 +8,7 @@ Email domain:     cam.ac.uk
 University of Cambridge Computing Service,
 Cambridge, England.
 
-Copyright (c) 1997-2015 University of Cambridge
+Copyright (c) 1997-2017 University of Cambridge
 All rights reserved
 
 
@@ -19,7 +19,7 @@ Written by:       Zoltan Herczeg
 Email local part: hzmester
 Emain domain:     freemail.hu
 
-Copyright(c) 2010-2015 Zoltan Herczeg
+Copyright(c) 2010-2017 Zoltan Herczeg
 All rights reserved.
 
 
@@ -30,7 +30,7 @@ Written by:       Zoltan Herczeg
 Email local part: hzmester
 Emain domain:     freemail.hu
 
-Copyright(c) 2009-2015 Zoltan Herczeg
+Copyright(c) 2009-2017 Zoltan Herczeg
 All rights reserved.
 
 

data/vendor/local/share/doc/pcre/ChangeLog

@@ -4,12 +4,151 @@ ChangeLog for PCRE
 Note that the PCRE 8.xx series (PCRE1) is now in a bugfix-only state. All
 development is happening in the PCRE2 10.xx series.
 
+Version 8.40 11-January-2017
+----------------------------
+
+1.  Using -o with -M in pcregrep could cause unnecessary repeated output when
+    the match extended over a line boundary.
+
+2.  Applied Chris Wilson's second patch (Bugzilla #1681) to CMakeLists.txt for
+    MSVC static compilation, putting the first patch under a new option.
+
+3.  Fix register overwite in JIT when SSE2 acceleration is enabled.
+
+4.  Ignore "show all captures" (/=) for DFA matching.
+
+5.  Fix JIT unaligned accesses on x86. Patch by Marc Mutz.
+
+6.  In any wide-character mode (8-bit UTF or any 16-bit or 32-bit mode),
+    without PCRE_UCP set, a negative character type such as \D in a positive
+    class should cause all characters greater than 255 to match, whatever else
+    is in the class. There was a bug that caused this not to happen if a
+    Unicode property item was added to such a class, for example [\D\P{Nd}] or
+    [\W\pL].
+
+7.  When pcretest was outputing information from a callout, the caret indicator
+    for the current position in the subject line was incorrect if it was after
+    an escape sequence for a character whose code point was greater than
+    \x{ff}.
+
+8.  A pattern such as (?<RA>abc)(?(R)xyz) was incorrectly compiled such that
+    the conditional was interpreted as a reference to capturing group 1 instead
+    of a test for recursion. Any group whose name began with R was
+    misinterpreted in this way. (The reference interpretation should only
+    happen if the group's name is precisely "R".)
+
+9.  A number of bugs have been mended relating to match start-up optimizations
+    when the first thing in a pattern is a positive lookahead. These all
+    applied only when PCRE_NO_START_OPTIMIZE was *not* set:
+
+    (a) A pattern such as (?=.*X)X$ was incorrectly optimized as if it needed
+        both an initial 'X' and a following 'X'.
+    (b) Some patterns starting with an assertion that started with .* were
+        incorrectly optimized as having to match at the start of the subject or
+        after a newline. There are cases where this is not true, for example,
+        (?=.*[A-Z])(?=.{8,16})(?!.*[\s]) matches after the start in lines that
+        start with spaces. Starting .* in an assertion is no longer taken as an
+        indication of matching at the start (or after a newline).
+
+
+Version 8.39 14-June-2016
+-------------------------
+
+1.  If PCRE_AUTO_CALLOUT was set on a pattern that had a (?# comment between
+    an item and its qualifier (for example, A(?#comment)?B) pcre_compile()
+    misbehaved. This bug was found by the LLVM fuzzer.
+
+2.  Similar to the above, if an isolated \E was present between an item and its
+    qualifier when PCRE_AUTO_CALLOUT was set, pcre_compile() misbehaved. This
+    bug was found by the LLVM fuzzer.
+
+3.  Further to 8.38/46, negated classes such as [^[:^ascii:]\d] were also not
+    working correctly in UCP mode.
+
+4.  The POSIX wrapper function regexec() crashed if the option REG_STARTEND
+    was set when the pmatch argument was NULL. It now returns REG_INVARG.
+
+5.  Allow for up to 32-bit numbers in the ordin() function in pcregrep.
+
+6.  An empty \Q\E sequence between an item and its qualifier caused
+    pcre_compile() to misbehave when auto callouts were enabled. This bug was
+    found by the LLVM fuzzer.
+
+7.  If a pattern that was compiled with PCRE_EXTENDED started with white
+    space or a #-type comment that was followed by (?-x), which turns off
+    PCRE_EXTENDED, and there was no subsequent (?x) to turn it on again,
+    pcre_compile() assumed that (?-x) applied to the whole pattern and
+    consequently mis-compiled it. This bug was found by the LLVM fuzzer.
+
+8.  A call of pcre_copy_named_substring() for a named substring whose number
+    was greater than the space in the ovector could cause a crash.
+
+9.  Yet another buffer overflow bug involved duplicate named groups with a
+    group that reset capture numbers (compare 8.38/7 below). Once again, I have
+    just allowed for more memory, even if not needed. (A proper fix is
+    implemented in PCRE2, but it involves a lot of refactoring.)
+
+10. pcre_get_substring_list() crashed if the use of \K in a match caused the
+    start of the match to be earlier than the end.
+
+11. Migrating appropriate PCRE2 JIT improvements to PCRE.
+
+12. A pattern such as /(?<=((?C)0))/, which has a callout inside a lookbehind
+    assertion, caused pcretest to generate incorrect output, and also to read
+    uninitialized memory (detected by ASAN or valgrind).
+
+13. A pattern that included (*ACCEPT) in the middle of a sufficiently deeply
+    nested set of parentheses of sufficient size caused an overflow of the
+    compiling workspace (which was diagnosed, but of course is not desirable).
+
+14. And yet another buffer overflow bug involving duplicate named groups, this
+    time nested, with a nested back reference. Yet again, I have just allowed
+    for more memory, because anything more needs all the refactoring that has
+    been done for PCRE2. An example pattern that provoked this bug is:
+    /((?J)(?'R'(?'R'(?'R'(?'R'(?'R'(?|(\k'R'))))))))/ and the bug was
+    registered as CVE-2016-1283.
+
+15. pcretest went into a loop if global matching was requested with an ovector
+    size less than 2. It now gives an error message. This bug was found by
+    afl-fuzz.
+
+16. An invalid pattern fragment such as (?(?C)0 was not diagnosing an error
+    ("assertion expected") when (?(?C) was not followed by an opening
+    parenthesis.
+
+17. Fixed typo ("&&" for "&") in pcre_study(). Fortunately, this could not
+    actually affect anything, by sheer luck.
+
+18. Applied Chris Wilson's patch (Bugzilla #1681) to CMakeLists.txt for MSVC
+    static compilation.
+
+19. Modified the RunTest script to incorporate a valgrind suppressions file so
+    that certain errors, provoked by the SSE2 instruction set when JIT is used,
+    are ignored.
+
+20. A racing condition is fixed in JIT reported by Mozilla.
+
+21. Minor code refactor to avoid "array subscript is below array bounds"
+    compiler warning.
+
+22. Minor code refactor to avoid "left shift of negative number" warning.
+
+23. Fix typo causing compile error when 16- or 32-bit JIT is compiled without
+    UCP support.
+
+24. Refactor to avoid compiler warnings in pcrecpp.cc.
+
+25. Refactor to fix a typo in pcre_jit_test.c
+
+26. Patch to support compiling pcrecpp.cc with Intel compiler.
+
+
 Version 8.38 23-November-2015
 -----------------------------
 
 1.  If a group that contained a recursive back reference also contained a
     forward reference subroutine call followed by a non-forward-reference
-    subroutine call, for example /.((?2)(?R)\1)()/, pcre2_compile() failed to
+    subroutine call, for example /.((?2)(?R)\1)()/, pcre_compile() failed to
     compile correct code, leading to undefined behaviour or an internally
     detected error. This bug was discovered by the LLVM fuzzer.
 

data/vendor/local/share/doc/pcre/LICENCE

@@ -25,7 +25,7 @@ Email domain:     cam.ac.uk
 University of Cambridge Computing Service,
 Cambridge, England.
 
-Copyright (c) 1997-2015 University of Cambridge
+Copyright (c) 1997-2017 University of Cambridge
 All rights reserved.
 
 
@@ -36,7 +36,7 @@ Written by:       Zoltan Herczeg
 Email local part: hzmester
 Emain domain:     freemail.hu
 
-Copyright(c) 2010-2015 Zoltan Herczeg
+Copyright(c) 2010-2017 Zoltan Herczeg
 All rights reserved.
 
 
@@ -47,7 +47,7 @@ Written by:       Zoltan Herczeg
 Email local part: hzmester
 Emain domain:     freemail.hu
 
-Copyright(c) 2009-2015 Zoltan Herczeg
+Copyright(c) 2009-2017 Zoltan Herczeg
 All rights reserved.
 
 

data/vendor/local/share/doc/pcre/NEWS

@@ -1,6 +1,21 @@
 News about PCRE releases
 ------------------------
 
+Release 8.40 11-January-2017
+----------------------------
+
+This is a bug-fix release.
+
+
+Release 8.39 14-June-2016
+-------------------------
+
+Some appropriate PCRE2 JIT improvements have been retro-fitted to PCRE1. Apart
+from that, this is another bug-fix release. Note that this library (now called
+PCRE1) is now being maintained for bug fixes only. New projects are advised to
+use the new PCRE2 libraries.
+
+
 Release 8.38 23-November-2015
 -----------------------------
 

data/vendor/local/share/doc/pcre/html/pcreapi.html

@@ -315,9 +315,8 @@ documentation for details of how to do this. It is a non-standard way of
 building PCRE, for use in environments that have limited stacks. Because of the
 greater use of memory management, it runs more slowly. Separate functions are
 provided so that special-purpose external code can be used for this case. When
-used, these functions are always called in a stack-like manner (last obtained,
-first freed), and always for memory blocks of the same size. There is a
-discussion about PCRE's stack usage in the
+used, these functions always allocate memory blocks of the same size. There is
+a discussion about PCRE's stack usage in the
 <a href="pcrestack.html"><b>pcrestack</b></a>
 documentation.
 </P>
@@ -2913,9 +2912,9 @@ Cambridge CB2 3QH, England.
 </P>
 <br><a name="SEC26" href="#TOC1">REVISION</a><br>
 <P>
-Last updated: 09 February 2014
+Last updated: 18 December 2015
 <br>
-Copyright &copy; 1997-2014 University of Cambridge.
+Copyright &copy; 1997-2015 University of Cambridge.
 <br>
 <p>
 Return to the <a href="index.html">PCRE index page</a>.

data/vendor/local/share/doc/pcre/html/pcrecompat.html

@@ -128,7 +128,7 @@ the pattern /^(a(b)?)+$/ in Perl leaves $2 unset, but in PCRE it is set to "b".
 14. PCRE's handling of duplicate subpattern numbers and duplicate subpattern
 names is not as general as Perl's. This is a consequence of the fact the PCRE
 works internally just with numbers, using an external table to translate
-between numbers and names. In particular, a pattern such as (?|(?<a>A)|(?<b)B),
+between numbers and names. In particular, a pattern such as (?|(?<a>A)|(?<b>B),
 where the two capturing parentheses have the same number but different names,
 is not supported, and causes an error at compile time. If it were allowed, it
 would not be possible to distinguish which parentheses matched, because both

data/vendor/local/share/doc/pcre/html/pcrepattern.html

@@ -358,24 +358,24 @@ When PCRE is compiled in EBCDIC mode, \a, \e, \f, \n, \r, and \t
 generate the appropriate EBCDIC code values. The \c escape is processed
 as specified for Perl in the <b>perlebcdic</b> document. The only characters
 that are allowed after \c are A-Z, a-z, or one of @, [, \, ], ^, _, or ?. Any
-other character provokes a compile-time error. The sequence \@ encodes
-character code 0; the letters (in either case) encode characters 1-26 (hex 01
-to hex 1A); [, \, ], ^, and _ encode characters 27-31 (hex 1B to hex 1F), and
-\? becomes either 255 (hex FF) or 95 (hex 5F).
+other character provokes a compile-time error. The sequence \c@ encodes
+character code 0; after \c the letters (in either case) encode characters 1-26
+(hex 01 to hex 1A); [, \, ], ^, and _ encode characters 27-31 (hex 1B to hex
+1F), and \c? becomes either 255 (hex FF) or 95 (hex 5F).
 </P>
 <P>
-Thus, apart from \?, these escapes generate the same character code values as
+Thus, apart from \c?, 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, \G always generates code value 7, which is BEL in ASCII
+differ. For example, \cG always generates code value 7, which is BEL in ASCII
 but DEL in EBCDIC.
 </P>
 <P>
-The sequence \? generates DEL (127, hex 7F) in an ASCII environment, but
+The sequence \c? 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 \? generate 95; otherwise it generates 255.
+values, PCRE makes \c? generate 95; otherwise it generates 255.
 </P>
 <P>
 After \0 up to two further octal digits are read. If there are fewer than two
@@ -1512,13 +1512,8 @@ J, U and X respectively.
 <P>
 When one of these option changes occurs at top level (that is, not inside
 subpattern parentheses), the change applies to the remainder of the pattern
-that follows. If the change is placed right at the start of a pattern, PCRE
-extracts it into the global options (and it will therefore show up in data
-extracted by the <b>pcre_fullinfo()</b> function).
-</P>
-<P>
-An option change within a subpattern (see below for a description of
-subpatterns) affects only that part of the subpattern that follows it, so
+that follows. An option change within a subpattern (see below for a description
+of subpatterns) affects only that part of the subpattern that follows it, so
 <pre>
   (a(?i)b)c
 </pre>
@@ -2160,6 +2155,14 @@ capturing is carried out only for positive assertions. (Perl sometimes, but not
 always, does do capturing in negative assertions.)
 </P>
 <P>
+WARNING: If a positive assertion containing one or more capturing subpatterns
+succeeds, but failure to match later in the pattern causes backtracking over
+this assertion, the captures within the assertion are reset only if no higher
+numbered captures are already set. This is, unfortunately, a fundamental
+limitation of the current implementation, and as PCRE1 is now in
+maintenance-only status, it is unlikely ever to change.
+</P>
+<P>
 For compatibility with Perl, assertion subpatterns may be repeated; though
 it makes no sense to assert the same thing several times, the side effect of
 capturing parentheses may occasionally be useful. In practice, there only three
@@ -3264,9 +3267,9 @@ Cambridge CB2 3QH, England.
 </P>
 <br><a name="SEC30" href="#TOC1">REVISION</a><br>
 <P>
-Last updated: 14 June 2015
+Last updated: 23 October 2016
 <br>
-Copyright &copy; 1997-2015 University of Cambridge.
+Copyright &copy; 1997-2016 University of Cambridge.
 <br>
 <p>
 Return to the <a href="index.html">PCRE index page</a>.