1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
2 |
------------------ |
------------------ |
3 |
|
|
4 |
Version 8.11 10-Oct-2010 |
Version 8.13 30-Apr-2011 |
5 |
|
------------------------ |
6 |
|
|
7 |
|
1. The Unicode data tables have been updated to Unicode 6.0.0. |
8 |
|
|
9 |
|
2. Two minor typos in pcre_internal.h have been fixed. |
10 |
|
|
11 |
|
3. Added #include <string.h> to pcre_scanner_unittest.cc, pcrecpp.cc, and |
12 |
|
pcrecpp_unittest.cc. They are needed for strcmp(), memset(), and strchr() |
13 |
|
in some environments (e.g. Solaris 10/SPARC using Sun Studio 12U2). |
14 |
|
|
15 |
|
4. There were a number of related bugs in the code for matching backrefences |
16 |
|
caselessly in UTF-8 mode when codes for the characters concerned were |
17 |
|
different numbers of bytes. For example, U+023A and U+2C65 are an upper |
18 |
|
and lower case pair, using 2 and 3 bytes, respectively. The main bugs were: |
19 |
|
(a) A reference to 3 copies of a 2-byte code matched only 2 of a 3-byte |
20 |
|
code. (b) A reference to 2 copies of a 3-byte code would not match 2 of a |
21 |
|
2-byte code at the end of the subject (it thought there wasn't enough data |
22 |
|
left). |
23 |
|
|
24 |
|
5. Comprehensive information about what went wrong is now returned by |
25 |
|
pcre_exec() and pcre_dfa_exec() when the UTF-8 string check fails, as long |
26 |
|
as the output vector has at least 2 elements. The offset of the start of |
27 |
|
the failing character and a reason code are placed in the vector. |
28 |
|
|
29 |
|
6. When the UTF-8 string check fails for pcre_compile(), the offset that is |
30 |
|
now returned is for the first byte of the failing character, instead of the |
31 |
|
last byte inspected. This is an incompatible change, but I hope it is small |
32 |
|
enough not to be a problem. It makes the returned offset consistent with |
33 |
|
pcre_exec() and pcre_dfa_exec(). |
34 |
|
|
35 |
|
7. pcretest now gives a text phrase as well as the error number when |
36 |
|
pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check |
37 |
|
failure, the offset and reason code are output. |
38 |
|
|
39 |
|
8. When \R was used with a maximizing quantifier it failed to skip backwards |
40 |
|
over a \r\n pair if the subsequent match failed. Instead, it just skipped |
41 |
|
back over a single character (\n). This seems wrong (because it treated the |
42 |
|
two characters as a single entity when going forwards), conflicts with the |
43 |
|
documentation that \R is equivalent to (?>\r\n|\n|...etc), and makes the |
44 |
|
behaviour of \R* different to (\R)*, which also seems wrong. The behaviour |
45 |
|
has been changed. |
46 |
|
|
47 |
|
9. Some internal refactoring has changed the processing so that the handling |
48 |
|
of the PCRE_CASELESS and PCRE_MULTILINE options is done entirely at compile |
49 |
|
time (the PCRE_DOTALL option was changed this way some time ago: version |
50 |
|
7.7 change 16). This has made it possible to abolish the OP_OPT op code, |
51 |
|
which was always a bit of a fudge. It also means that there is one less |
52 |
|
argument for the match() function, which reduces its stack requirements |
53 |
|
slightly. This change also fixes an incompatibility with Perl: the pattern |
54 |
|
(?i:([^b]))(?1) should not match "ab", but previously PCRE gave a match. |
55 |
|
|
56 |
|
10. More internal refactoring has drastically reduced the number of recursive |
57 |
|
calls to match() for possessively repeated groups such as (abc)++ when |
58 |
|
using pcre_exec(). |
59 |
|
|
60 |
|
11. While implementing 10, a number of bugs in the handling of groups were |
61 |
|
discovered and fixed: |
62 |
|
|
63 |
|
(?<=(a)+) was not diagnosed as invalid (non-fixed-length lookbehind). |
64 |
|
(a|)*(?1) gave a compile-time internal error. |
65 |
|
((a|)+)+ did not notice that the outer group could match an empty string. |
66 |
|
(^a|^)+ was not marked as anchored. |
67 |
|
(.*a|.*)+ was not marked as matching at start or after a newline. |
68 |
|
|
69 |
|
12. Yet more internal refactoring has removed another argument from the match() |
70 |
|
function. Special calls to this function are now indicated by setting a |
71 |
|
value in a variable in the "match data" data block. |
72 |
|
|
73 |
|
13. Be more explicit in pcre_study() instead of relying on "default" for |
74 |
|
opcodes that mean there is no starting character; this means that when new |
75 |
|
ones are added and accidentally left out of pcre_study(), testing should |
76 |
|
pick them up. |
77 |
|
|
78 |
|
|
79 |
|
Version 8.12 15-Jan-2011 |
80 |
|
------------------------ |
81 |
|
|
82 |
|
1. Fixed some typos in the markup of the man pages, and wrote a script that |
83 |
|
checks for such things as part of the documentation building process. |
84 |
|
|
85 |
|
2. On a big-endian 64-bit system, pcregrep did not correctly process the |
86 |
|
--match-limit and --recursion-limit options (added for 8.11). In |
87 |
|
particular, this made one of the standard tests fail. (The integer value |
88 |
|
went into the wrong half of a long int.) |
89 |
|
|
90 |
|
3. If the --colour option was given to pcregrep with -v (invert match), it |
91 |
|
did strange things, either producing crazy output, or crashing. It should, |
92 |
|
of course, ignore a request for colour when reporting lines that do not |
93 |
|
match. |
94 |
|
|
95 |
|
4. Another pcregrep bug caused similar problems if --colour was specified with |
96 |
|
-M (multiline) and the pattern match finished with a line ending. |
97 |
|
|
98 |
|
5. In pcregrep, when a pattern that ended with a literal newline sequence was |
99 |
|
matched in multiline mode, the following line was shown as part of the |
100 |
|
match. This seems wrong, so I have changed it. |
101 |
|
|
102 |
|
6. Another pcregrep bug in multiline mode, when --colour was specified, caused |
103 |
|
the check for further matches in the same line (so they could be coloured) |
104 |
|
to overrun the end of the current line. If another match was found, it was |
105 |
|
incorrectly shown (and then shown again when found in the next line). |
106 |
|
|
107 |
|
7. If pcregrep was compiled under Windows, there was a reference to the |
108 |
|
function pcregrep_exit() before it was defined. I am assuming this was |
109 |
|
the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was |
110 |
|
reported by a user. I've moved the definition above the reference. |
111 |
|
|
112 |
|
|
113 |
|
Version 8.11 10-Dec-2010 |
114 |
------------------------ |
------------------------ |
115 |
|
|
116 |
1. (*THEN) was not working properly if there were untried alternatives prior |
1. (*THEN) was not working properly if there were untried alternatives prior |
117 |
to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it |
to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it |
118 |
backtracked to try for "b" instead of moving to the next alternative branch |
backtracked to try for "b" instead of moving to the next alternative branch |
119 |
at the same level (in this case, to look for "c"). The Perl documentation |
at the same level (in this case, to look for "c"). The Perl documentation |
120 |
is clear that when (*THEN) is backtracked onto, it goes to the "next |
is clear that when (*THEN) is backtracked onto, it goes to the "next |
121 |
alternative in the innermost enclosing group". |
alternative in the innermost enclosing group". |
122 |
|
|
123 |
2. (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern |
2. (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern |
124 |
such as (A(*COMMIT)B(*THEN)C|D) any failure after matching A should |
such as (A(*COMMIT)B(*THEN)C|D) any failure after matching A should |
125 |
result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and |
result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and |
126 |
(*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides |
(*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides |
127 |
(*THEN). |
(*THEN). |
128 |
|
|
129 |
3. If \s appeared in a character class, it removed the VT character from |
3. If \s appeared in a character class, it removed the VT character from |
130 |
the class, even if it had been included by some previous item, for example |
the class, even if it had been included by some previous item, for example |
131 |
in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part |
in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part |
132 |
of \s, but is part of the POSIX "space" class.) |
of \s, but is part of the POSIX "space" class.) |
133 |
|
|
134 |
4. A partial match never returns an empty string (because you can always |
4. A partial match never returns an empty string (because you can always |
135 |
match an empty string at the end of the subject); however the checking for |
match an empty string at the end of the subject); however the checking for |
136 |
an empty string was starting at the "start of match" point. This has been |
an empty string was starting at the "start of match" point. This has been |
140 |
(previously it gave "no match"). |
(previously it gave "no match"). |
141 |
|
|
142 |
5. Changes have been made to the way PCRE_PARTIAL_HARD affects the matching |
5. Changes have been made to the way PCRE_PARTIAL_HARD affects the matching |
143 |
of $, \z, \Z, \b, and \B. If the match point is at the end of the string, |
of $, \z, \Z, \b, and \B. If the match point is at the end of the string, |
144 |
previously a full match would be given. However, setting PCRE_PARTIAL_HARD |
previously a full match would be given. However, setting PCRE_PARTIAL_HARD |
145 |
has an implication that the given string is incomplete (because a partial |
has an implication that the given string is incomplete (because a partial |
146 |
match is preferred over a full match). For this reason, these items now |
match is preferred over a full match). For this reason, these items now |
147 |
give a partial match in this situation. [Aside: previously, the one case |
give a partial match in this situation. [Aside: previously, the one case |
148 |
/t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial |
/t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial |
149 |
match rather than a full match, which was wrong by the old rules, but is |
match rather than a full match, which was wrong by the old rules, but is |
150 |
now correct.] |
now correct.] |
151 |
|
|
152 |
6. There was a bug in the handling of #-introduced comments, recognized when |
6. There was a bug in the handling of #-introduced comments, recognized when |
153 |
PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set. |
PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set. |
154 |
If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose |
If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose |
155 |
UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when |
UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when |
156 |
scanning for the end of the comment. (*Character* 0x85 is an "any" newline, |
scanning for the end of the comment. (*Character* 0x85 is an "any" newline, |
157 |
but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several |
but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several |
158 |
places in pcre_compile(). |
places in pcre_compile(). |
159 |
|
|
160 |
7. Related to (6) above, when pcre_compile() was skipping #-introduced |
7. Related to (6) above, when pcre_compile() was skipping #-introduced |
161 |
comments when looking ahead for named forward references to subpatterns, |
comments when looking ahead for named forward references to subpatterns, |
162 |
the only newline sequence it recognized was NL. It now handles newlines |
the only newline sequence it recognized was NL. It now handles newlines |
163 |
according to the set newline convention. |
according to the set newline convention. |
164 |
|
|
165 |
8. SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the |
8. SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the |
166 |
former, but used strtoul(), whereas pcretest avoided strtoul() but did not |
former, but used strtoul(), whereas pcretest avoided strtoul() but did not |
167 |
cater for a lack of strerror(). These oversights have been fixed. |
cater for a lack of strerror(). These oversights have been fixed. |
168 |
|
|
169 |
9. Added --match-limit and --recursion-limit to pcregrep. |
9. Added --match-limit and --recursion-limit to pcregrep. |
170 |
|
|
171 |
10. Added two casts needed to build with Visual Studio when NO_RECURSE is set. |
10. Added two casts needed to build with Visual Studio when NO_RECURSE is set. |
172 |
|
|
173 |
11. When the -o option was used, pcregrep was setting a return code of 1, even |
11. When the -o option was used, pcregrep was setting a return code of 1, even |
174 |
when matches were found, and --line-buffered was not being honoured. |
when matches were found, and --line-buffered was not being honoured. |
175 |
|
|
176 |
12. Added an optional parentheses number to the -o and --only-matching options |
12. Added an optional parentheses number to the -o and --only-matching options |
177 |
of pcregrep. |
of pcregrep. |
178 |
|
|
179 |
13. Imitating Perl's /g action for multiple matches is tricky when the pattern |
13. Imitating Perl's /g action for multiple matches is tricky when the pattern |
180 |
can match an empty string. The code to do it in pcretest and pcredemo |
can match an empty string. The code to do it in pcretest and pcredemo |
181 |
needed fixing: |
needed fixing: |
182 |
|
|
183 |
(a) When the newline convention was "crlf", pcretest got it wrong, skipping |
(a) When the newline convention was "crlf", pcretest got it wrong, skipping |
184 |
only one byte after an empty string match just before CRLF (this case |
only one byte after an empty string match just before CRLF (this case |
185 |
just got forgotten; "any" and "anycrlf" were OK). |
just got forgotten; "any" and "anycrlf" were OK). |
186 |
|
|
187 |
(b) The pcretest code also had a bug, causing it to loop forever in UTF-8 |
(b) The pcretest code also had a bug, causing it to loop forever in UTF-8 |
188 |
mode when an empty string match preceded an ASCII character followed by |
mode when an empty string match preceded an ASCII character followed by |
189 |
a non-ASCII character. (The code for advancing by one character rather |
a non-ASCII character. (The code for advancing by one character rather |
190 |
than one byte was nonsense.) |
than one byte was nonsense.) |
191 |
|
|
192 |
(c) The pcredemo.c sample program did not have any code at all to handle |
(c) The pcredemo.c sample program did not have any code at all to handle |
193 |
the cases when CRLF is a valid newline sequence. |
the cases when CRLF is a valid newline sequence. |
194 |
|
|
195 |
|
14. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given |
196 |
|
as a starting offset was within the subject string. There is now a new |
197 |
|
error, PCRE_ERROR_BADOFFSET, which is returned if the starting offset is |
198 |
|
negative or greater than the length of the string. In order to test this, |
199 |
|
pcretest is extended to allow the setting of negative starting offsets. |
200 |
|
|
201 |
|
15. In both pcre_exec() and pcre_dfa_exec() the code for checking that the |
202 |
|
starting offset points to the beginning of a UTF-8 character was |
203 |
|
unnecessarily clumsy. I tidied it up. |
204 |
|
|
205 |
|
16. Added PCRE_ERROR_SHORTUTF8 to make it possible to distinguish between a |
206 |
|
bad UTF-8 sequence and one that is incomplete when using PCRE_PARTIAL_HARD. |
207 |
|
|
208 |
|
17. Nobody had reported that the --include_dir option, which was added in |
209 |
|
release 7.7 should have been called --include-dir (hyphen, not underscore) |
210 |
|
for compatibility with GNU grep. I have changed it to --include-dir, but |
211 |
|
left --include_dir as an undocumented synonym, and the same for |
212 |
|
--exclude-dir, though that is not available in GNU grep, at least as of |
213 |
|
release 2.5.4. |
214 |
|
|
215 |
|
18. At a user's suggestion, the macros GETCHAR and friends (which pick up UTF-8 |
216 |
|
characters from a string of bytes) have been redefined so as not to use |
217 |
|
loops, in order to improve performance in some environments. At the same |
218 |
|
time, I abstracted some of the common code into auxiliary macros to save |
219 |
|
repetition (this should not affect the compiled code). |
220 |
|
|
221 |
|
19. If \c was followed by a multibyte UTF-8 character, bad things happened. A |
222 |
|
compile-time error is now given if \c is not followed by an ASCII |
223 |
|
character, that is, a byte less than 128. (In EBCDIC mode, the code is |
224 |
|
different, and any byte value is allowed.) |
225 |
|
|
226 |
|
20. Recognize (*NO_START_OPT) at the start of a pattern to set the PCRE_NO_ |
227 |
|
START_OPTIMIZE option, which is now allowed at compile time - but just |
228 |
|
passed through to pcre_exec() or pcre_dfa_exec(). This makes it available |
229 |
|
to pcregrep and other applications that have no direct access to PCRE |
230 |
|
options. The new /Y option in pcretest sets this option when calling |
231 |
|
pcre_compile(). |
232 |
|
|
233 |
|
21. Change 18 of release 8.01 broke the use of named subpatterns for recursive |
234 |
|
back references. Groups containing recursive back references were forced to |
235 |
|
be atomic by that change, but in the case of named groups, the amount of |
236 |
|
memory required was incorrectly computed, leading to "Failed: internal |
237 |
|
error: code overflow". This has been fixed. |
238 |
|
|
239 |
|
22. Some patches to pcre_stringpiece.h, pcre_stringpiece_unittest.cc, and |
240 |
|
pcretest.c, to avoid build problems in some Borland environments. |
241 |
|
|
242 |
|
|
243 |
Version 8.10 25-Jun-2010 |
Version 8.10 25-Jun-2010 |