חדשות, עדכונים, מדריכים ועזרים | עדכוני תוכנות ואפליקציות - (26.09.14) - גרסה חדשה: PCRE 8.36

(26.09.14) - גרסה חדשה: PCRE 8.36

עדכוני תוכנות ואפליקציות

חדשות, עדכונים, מדריכים ועזרים


פרטים נוספים:
http://pcre.org/changelog.txt
http://pcre.org/news.txt

מה חדש:
1.  Got rid of some compiler warnings in the C++ modules that were shown up by
    -Wmissing-field-initializers and -Wunused-parameter.

2.  The tests for quantifiers being too big (greater than 65535) were being
    applied after reading the number, and stupidly assuming that integer
    overflow would give a negative number. The tests are now applied as the
    numbers are read.

3.  Tidy code in pcre_exec.c where two branches that used to be different are
    now the same.

4.  The JIT compiler did not generate match limit checks for certain
    bracketed expressions with quantifiers. This may lead to exponential
    backtracking, instead of returning with PCRE_ERROR_MATCHLIMIT. This
    issue should be resolved now.

5.  Fixed an issue, which occures when nested alternatives are optimized
    with table jumps.

6.  Inserted two casts and changed some ints to size_t in the light of some
    reported 64-bit compiler warnings (Bugzilla 1477).

7.  Fixed a bug concerned with zero-minimum possessive groups that could match
    an empty string, which sometimes were behaving incorrectly in the
    interpreter (though correctly in the JIT matcher). This pcretest input is
    an example:

      '\A(?:[^"]++|"(?:[^"]*+|"")*+")++'
      NON QUOTED "QUOT""ED" AFTER "NOT MATCHED

    the interpreter was reporting a match of 'NON QUOTED ' only, whereas the
    JIT matcher and Perl both matched 'NON QUOTED "QUOT""ED" AFTER '. The test
    for an empty string was breaking the inner loop and carrying on at a lower
    level, when possessive repeated groups should always return to a higher
    level as they have no backtrack points in them. The empty string test now
    occurs at the outer level.

8.  Fixed a bug that was incorrectly auto-possessifying \w+ in the pattern
    ^\w+(?>\s*)(?<=\w) which caused it not to match "test test".

9.  Give a compile-time error for \o{} (as Perl does) and for \x{} (which Perl
    doesn't).

10. Change 8.34/15 introduced a bug that caused the amount of memory needed
    to hold a pattern to be incorrectly computed (too small) when there were
    named back references to duplicated names. This could cause "internal
    error: code overflow" or "double free or corruption" or other memory
    handling errors.

11. When named subpatterns had the same prefixes, back references could be
    confused. For example, in this pattern:

      /(?P<Name>a)?(?P<Name2>b)?(?(<Name>)c|d)*l/

    the reference to 'Name' was incorrectly treated as a reference to a
    duplicate name.

12. A pattern such as /^s?c/mi8 where the optional character has more than
    one "other case" was incorrectly compiled such that it would only try to
    match starting at "c".

13. When a pattern starting with \s was studied, VT was not included in the
    list of possible starting characters; this should have been part of the
    8.34/18 patch.

14. If a character class started [\Qx]... where x is any character, the class
    was incorrectly terminated at the ].

15. If a pattern that started with a caseless match for a character with more
    than one "other case" was studied, PCRE did not set up the starting code
    unit bit map for the list of possible characters. Now it does. This is an
    optimization improvement, not a bug fix.

16. The Unicode data tables have been updated to Unicode 7.0.0.

17. Fixed a number of memory leaks in pcregrep.

18. Avoid a compiler warning (from some compilers) for a function call with
    a cast that removes "const" from an lvalue by using an intermediate
    variable (to which the compiler does not object).

19. Incorrect code was compiled if a group that contained an internal recursive
    back reference was optional (had quantifier with a minimum of zero). This
    example compiled incorrect code: /(((a\2)|(a*)\g<-1>))*/ and other examples
    caused segmentation faults because of stack overflows at compile time.

20. A pattern such as /((?(R)a|(?1)))+/, which contains a recursion within a
    group that is quantified with an indefinite repeat, caused a compile-time
    loop which used up all the system stack and provoked a segmentation fault.
    This was not the same bug as 19 above.

21. Add PCRECPP_EXP_DECL declaration to operator<< in pcre_stringpiece.h.
    Patch by Mike Frysinger.