| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 8.10 03-Jun-2010 |
Version 8.11 10-Oct-2010 |
| 5 |
|
------------------------ |
| 6 |
|
|
| 7 |
|
1. (*THEN) was not working properly if there were untried alternatives prior |
| 8 |
|
to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it |
| 9 |
|
backtracked to try for "b" instead of moving to the next alternative branch |
| 10 |
|
at the same level (in this case, to look for "c"). The Perl documentation |
| 11 |
|
is clear that when (*THEN) is backtracked onto, it goes to the "next |
| 12 |
|
alternative in the innermost enclosing group". |
| 13 |
|
|
| 14 |
|
2. (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern |
| 15 |
|
such as (A(*COMMIT)B(*THEN)C|D) any failure after matching A should |
| 16 |
|
result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and |
| 17 |
|
(*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides |
| 18 |
|
(*THEN). |
| 19 |
|
|
| 20 |
|
3. If \s appeared in a character class, it removed the VT character from |
| 21 |
|
the class, even if it had been included by some previous item, for example |
| 22 |
|
in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part |
| 23 |
|
of \s, but is part of the POSIX "space" class.) |
| 24 |
|
|
| 25 |
|
4. A partial match never returns an empty string (because you can always |
| 26 |
|
match an empty string at the end of the subject); however the checking for |
| 27 |
|
an empty string was starting at the "start of match" point. This has been |
| 28 |
|
changed to the "earliest inspected character" point, because the returned |
| 29 |
|
data for a partial match starts at this character. This means that, for |
| 30 |
|
example, /(?<=abc)def/ gives a partial match for the subject "abc" |
| 31 |
|
(previously it gave "no match"). |
| 32 |
|
|
| 33 |
|
5. Changes have been made to the way PCRE_PARTIAL_HARD affects the matching |
| 34 |
|
of $, \z, \Z, \b, and \B. If the match point is at the end of the string, |
| 35 |
|
previously a full match would be given. However, setting PCRE_PARTIAL_HARD |
| 36 |
|
has an implication that the given string is incomplete (because a partial |
| 37 |
|
match is preferred over a full match). For this reason, these items now |
| 38 |
|
give a partial match in this situation. [Aside: previously, the one case |
| 39 |
|
/t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial |
| 40 |
|
match rather than a full match, which was wrong by the old rules, but is |
| 41 |
|
now correct.] |
| 42 |
|
|
| 43 |
|
6. There was a bug in the handling of #-introduced comments, recognized when |
| 44 |
|
PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set. |
| 45 |
|
If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose |
| 46 |
|
UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when |
| 47 |
|
scanning for the end of the comment. (*Character* 0x85 is an "any" newline, |
| 48 |
|
but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several |
| 49 |
|
places in pcre_compile(). |
| 50 |
|
|
| 51 |
|
7. Related to (6) above, when pcre_compile() was skipping #-introduced |
| 52 |
|
comments when looking ahead for named forward references to subpatterns, |
| 53 |
|
the only newline sequence it recognized was NL. It now handles newlines |
| 54 |
|
according to the set newline convention. |
| 55 |
|
|
| 56 |
|
8. SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the |
| 57 |
|
former, but used strtoul(), whereas pcretest avoided strtoul() but did not |
| 58 |
|
cater for a lack of strerror(). These oversights have been fixed. |
| 59 |
|
|
| 60 |
|
9. Added --match-limit and --recursion-limit to pcregrep. |
| 61 |
|
|
| 62 |
|
10. Added two casts needed to build with Visual Studio when NO_RECURSE is set. |
| 63 |
|
|
| 64 |
|
11. When the -o option was used, pcregrep was setting a return code of 1, even |
| 65 |
|
when matches were found, and --line-buffered was not being honoured. |
| 66 |
|
|
| 67 |
|
12. Added an optional parentheses number to the -o and --only-matching options |
| 68 |
|
of pcregrep. |
| 69 |
|
|
| 70 |
|
13. Imitating Perl's /g action for multiple matches is tricky when the pattern |
| 71 |
|
can match an empty string. The code to do it in pcretest and pcredemo |
| 72 |
|
needed fixing: |
| 73 |
|
|
| 74 |
|
(a) When the newline convention was "crlf", pcretest got it wrong, skipping |
| 75 |
|
only one byte after an empty string match just before CRLF (this case |
| 76 |
|
just got forgotten; "any" and "anycrlf" were OK). |
| 77 |
|
|
| 78 |
|
(b) The pcretest code also had a bug, causing it to loop forever in UTF-8 |
| 79 |
|
mode when an empty string match preceded an ASCII character followed by |
| 80 |
|
a non-ASCII character. (The code for advancing by one character rather |
| 81 |
|
than one byte was nonsense.) |
| 82 |
|
|
| 83 |
|
(c) The pcredemo.c sample program did not have any code at all to handle |
| 84 |
|
the cases when CRLF is a valid newline sequence. |
| 85 |
|
|
| 86 |
|
14. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given |
| 87 |
|
as a starting offset was within the subject string. There is now a new |
| 88 |
|
error, PCRE_ERROR_BADOFFSET, which is returned if the starting offset is |
| 89 |
|
negative or greater than the length of the string. In order to test this, |
| 90 |
|
pcretest is extended to allow the setting of negative starting offsets. |
| 91 |
|
|
| 92 |
|
15. In both pcre_exec() and pcre_dfa_exec() the code for checking that the |
| 93 |
|
starting offset points to the beginning of a UTF-8 character was |
| 94 |
|
unnecessarily clumsy. I tidied it up. |
| 95 |
|
|
| 96 |
|
16. Added PCRE_ERROR_SHORTUTF8 to make it possible to distinguish between a |
| 97 |
|
bad UTF-8 sequence and one that is incomplete. |
| 98 |
|
|
| 99 |
|
17. Nobody had reported that the --include_dir option, which was added in |
| 100 |
|
release 7.7 should have been called --include-dir (hyphen, not underscore) |
| 101 |
|
for compatibility with GNU grep. I have changed it to --include-dir, but |
| 102 |
|
left --include_dir as an undocumented synonym, and the same for |
| 103 |
|
--exclude-dir, though that is not available in GNU grep, at least as of |
| 104 |
|
release 2.5.4. |
| 105 |
|
|
| 106 |
|
|
| 107 |
|
Version 8.10 25-Jun-2010 |
| 108 |
------------------------ |
------------------------ |
| 109 |
|
|
| 110 |
1. Added support for (*MARK:ARG) and for ARG additions to PRUNE, SKIP, and |
1. Added support for (*MARK:ARG) and for ARG additions to PRUNE, SKIP, and |
| 145 |
11. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was |
11. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was |
| 146 |
studied, and the match started with a letter with a code point greater than |
studied, and the match started with a letter with a code point greater than |
| 147 |
127 whose first byte was different to the first byte of the other case of |
127 whose first byte was different to the first byte of the other case of |
| 148 |
the letter, the other case of this starting letter was not recognized |
the letter, the other case of this starting letter was not recognized |
| 149 |
(#976). |
(#976). |
| 150 |
|
|
| 151 |
12. If a pattern that was studied started with a repeated Unicode property |
12. If a pattern that was studied started with a repeated Unicode property |
| 171 |
|
|
| 172 |
17. Added a check for running out of memory when PCRE is compiled with |
17. Added a check for running out of memory when PCRE is compiled with |
| 173 |
--disable-stack-for-recursion (#990). |
--disable-stack-for-recursion (#990). |
| 174 |
|
|
| 175 |
18. If the last data line in a file for pcretest does not have a newline on |
18. If the last data line in a file for pcretest does not have a newline on |
| 176 |
the end, a newline was missing in the output. |
the end, a newline was missing in the output. |
| 177 |
|
|
| 178 |
|
19. The default pcre_chartables.c file recognizes only ASCII characters (values |
| 179 |
|
less than 128) in its various bitmaps. However, there is a facility for |
| 180 |
|
generating tables according to the current locale when PCRE is compiled. It |
| 181 |
|
turns out that in some environments, 0x85 and 0xa0, which are Unicode space |
| 182 |
|
characters, are recognized by isspace() and therefore were getting set in |
| 183 |
|
these tables, and indeed these tables seem to approximate to ISO 8859. This |
| 184 |
|
caused a problem in UTF-8 mode when pcre_study() was used to create a list |
| 185 |
|
of bytes that can start a match. For \s, it was including 0x85 and 0xa0, |
| 186 |
|
which of course cannot start UTF-8 characters. I have changed the code so |
| 187 |
|
that only real ASCII characters (less than 128) and the correct starting |
| 188 |
|
bytes for UTF-8 encodings are set for characters greater than 127 when in |
| 189 |
|
UTF-8 mode. (When PCRE_UCP is set - see 9 above - the code is different |
| 190 |
|
altogether.) |
| 191 |
|
|
| 192 |
|
20. Added the /T option to pcretest so as to be able to run tests with non- |
| 193 |
|
standard character tables, thus making it possible to include the tests |
| 194 |
|
used for 19 above in the standard set of tests. |
| 195 |
|
|
| 196 |
|
21. A pattern such as (?&t)(?#()(?(DEFINE)(?<t>a)) which has a forward |
| 197 |
|
reference to a subpattern the other side of a comment that contains an |
| 198 |
|
opening parenthesis caused either an internal compiling error, or a |
| 199 |
|
reference to the wrong subpattern. |
| 200 |
|
|
| 201 |
|
|
| 202 |
Version 8.02 19-Mar-2010 |
Version 8.02 19-Mar-2010 |