1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
2 |
------------------ |
------------------ |
3 |
|
|
4 |
Version 7.4 10-Sep-07 |
Version 8.00 ??-???-?? |
5 |
|
---------------------- |
6 |
|
|
7 |
|
1. The table for translating pcre_compile() error codes into POSIX error codes |
8 |
|
was out-of-date, and there was no check on the pcre_compile() error code |
9 |
|
being within the table. This could lead to an OK return being given in |
10 |
|
error. |
11 |
|
|
12 |
|
2. Changed the call to open a subject file in pcregrep from fopen(pathname, |
13 |
|
"r") to fopen(pathname, "rb"), which fixed a problem with some of the tests |
14 |
|
in a Windows environment. |
15 |
|
|
16 |
|
3. The pcregrep --count option prints the count for each file even when it is |
17 |
|
zero, as does GNU grep. However, pcregrep was also printing all files when |
18 |
|
--files-with-matches was added. Now, when both options are given, it prints |
19 |
|
counts only for those files that have at least one match. (GNU grep just |
20 |
|
prints the file name in this circumstance, but including the count seems |
21 |
|
more useful - otherwise, why use --count?) Also ensured that the |
22 |
|
combination -clh just lists non-zero counts, with no names. |
23 |
|
|
24 |
|
4. The long form of the pcregrep -F option was incorrectly implemented as |
25 |
|
--fixed_strings instead of --fixed-strings. This is an incompatible change, |
26 |
|
but it seems right to fix it, and I didn't think it was worth preserving |
27 |
|
the old behaviour. |
28 |
|
|
29 |
|
5. The command line items --regex=pattern and --regexp=pattern were not |
30 |
|
recognized by pcregrep, which required --regex pattern or --regexp pattern |
31 |
|
(with a space rather than an '='). The man page documented the '=' forms, |
32 |
|
which are compatible with GNU grep; these now work. |
33 |
|
|
34 |
|
6. No libpcreposix.pc file was created for pkg-config; there was just |
35 |
|
libpcre.pc and libpcrecpp.pc. The omission has been rectified. |
36 |
|
|
37 |
|
7. Added #ifndef SUPPORT_UCP into the pcre_ucd.c module, to reduce its size |
38 |
|
when UCP support is not needed, by modifying the Python script that |
39 |
|
generates it from Unicode data files. This should not matter if the module |
40 |
|
is correctly used as a library, but I received one complaint about 50K of |
41 |
|
unwanted data. My guess is that the person linked everything into his |
42 |
|
program rather than using a library. Anyway, it does no harm. |
43 |
|
|
44 |
|
8. A pattern such as /\x{123}{2,2}+/8 was incorrectly compiled; the trigger |
45 |
|
was a minimum greater than 1 for a wide character in a possessive |
46 |
|
repetition. The same bug could also affect patterns like /(\x{ff}{0,2})*/8 |
47 |
|
which had an unlimited repeat of a nested, fixed maximum repeat of a wide |
48 |
|
character. Chaos in the form of incorrect output or a compiling loop could |
49 |
|
result. |
50 |
|
|
51 |
|
9. The restrictions on what a pattern can contain when partial matching is |
52 |
|
requested for pcre_exec() have been removed. All patterns can now be |
53 |
|
partially matched by this function. In addition, if there are at least two |
54 |
|
slots in the offset vector, the offset of the earliest inspected character |
55 |
|
for the match and the offset of the end of the subject are set in them when |
56 |
|
PCRE_ERROR_PARTIAL is returned. |
57 |
|
|
58 |
|
10. Partial matching has been split into two forms: PCRE_PARTIAL_SOFT, which is |
59 |
|
synonymous with PCRE_PARTIAL, for backwards compatibility, and |
60 |
|
PCRE_PARTIAL_HARD, which causes a partial match to supersede a full match, |
61 |
|
and may be more useful for multi-segment matching, especially with |
62 |
|
pcre_exec(). |
63 |
|
|
64 |
|
11. Partial matching with pcre_exec() is now more intuitive. A partial match |
65 |
|
used to be given if ever the end of the subject was reached; now it is |
66 |
|
given only if matching could not proceed because another character was |
67 |
|
needed. This makes a difference in some odd cases such as Z(*FAIL) with the |
68 |
|
string "Z", which now yields "no match" instead of "partial match". In the |
69 |
|
case of pcre_dfa_exec(), "no match" is given if every matching path for the |
70 |
|
final character ended with (*FAIL). |
71 |
|
|
72 |
|
12. Restarting a match using pcre_dfa_exec() after a partial match did not work |
73 |
|
if the pattern had a "must contain" character that was already found in the |
74 |
|
earlier partial match, unless partial matching was again requested. For |
75 |
|
example, with the pattern /dog.(body)?/, the "must contain" character is |
76 |
|
"g". If the first part-match was for the string "dog", restarting with |
77 |
|
"sbody" failed. This bug has been fixed. |
78 |
|
|
79 |
|
13. The string returned by pcre_dfa_exec() after a partial match has been |
80 |
|
changed so that it starts at the first inspected character rather than the |
81 |
|
first character of the match. This makes a difference only if the pattern |
82 |
|
starts with a lookbehind assertion or \b or \B (\K is not supported by |
83 |
|
pcre_dfa_exec()). It's an incompatible change, but it makes the two |
84 |
|
matching functions compatible, and I think it's the right thing to do. |
85 |
|
|
86 |
|
14. Added a pcredemo man page, created automatically from the pcredemo.c file, |
87 |
|
so that the demonstration program is easily available in environments where |
88 |
|
PCRE has not been installed from source. |
89 |
|
|
90 |
|
15. Arranged to add -DPCRE_STATIC to cflags in libpcre.pc, libpcreposix.cp, |
91 |
|
libpcrecpp.pc and pcre-config when PCRE is not compiled as a shared |
92 |
|
library. |
93 |
|
|
94 |
|
16. Added REG_UNGREEDY to the pcreposix interface, at the request of a user. |
95 |
|
It maps to PCRE_UNGREEDY. It is not, of course, POSIX-compatible, but it |
96 |
|
is not the first non-POSIX option to be added. Clearly some people find |
97 |
|
these options useful. |
98 |
|
|
99 |
|
17. If a caller to the POSIX matching function regexec() passes a non-zero |
100 |
|
value for nmatch with a NULL value for pmatch, the value of |
101 |
|
nmatch is forced to zero. |
102 |
|
|
103 |
|
18. RunGrepTest did not have a test for the availability of the -u option of |
104 |
|
the diff command, as RunTest does. It now checks in the same way as |
105 |
|
RunTest, and also checks for the -b option. |
106 |
|
|
107 |
|
19. If an odd number of negated classes containing just a single character |
108 |
|
interposed, within parentheses, between a forward reference to a named |
109 |
|
subpattern and the definition of the subpattern, compilation crashed with |
110 |
|
an internal error, complaining that it could not find the referenced |
111 |
|
subpattern. An example of a crashing pattern is /(?&A)(([^m])(?<A>))/. |
112 |
|
[The bug was that it was starting one character too far in when skipping |
113 |
|
over the character class, thus treating the ] as data rather than |
114 |
|
terminating the class. This meant it could skip too much.] |
115 |
|
|
116 |
|
20. Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly implement the |
117 |
|
/g option in pcretest when the pattern contains \K, which makes it possible |
118 |
|
to have an empty string match not at the start, even when the pattern is |
119 |
|
anchored. Updated pcretest and pcredemo to use this option. |
120 |
|
|
121 |
|
21. If the maximum number of capturing subpatterns in a recursion was greater |
122 |
|
than the maximum at the outer level, the higher number was returned, but |
123 |
|
with unset values at the outer level. The correct (outer level) value is |
124 |
|
now given. |
125 |
|
|
126 |
|
|
127 |
|
Version 7.9 11-Apr-09 |
128 |
|
--------------------- |
129 |
|
|
130 |
|
1. When building with support for bzlib/zlib (pcregrep) and/or readline |
131 |
|
(pcretest), all targets were linked against these libraries. This included |
132 |
|
libpcre, libpcreposix, and libpcrecpp, even though they do not use these |
133 |
|
libraries. This caused unwanted dependencies to be created. This problem |
134 |
|
has been fixed, and now only pcregrep is linked with bzlib/zlib and only |
135 |
|
pcretest is linked with readline. |
136 |
|
|
137 |
|
2. The "typedef int BOOL" in pcre_internal.h that was included inside the |
138 |
|
"#ifndef FALSE" condition by an earlier change (probably 7.8/18) has been |
139 |
|
moved outside it again, because FALSE and TRUE are already defined in AIX, |
140 |
|
but BOOL is not. |
141 |
|
|
142 |
|
3. The pcre_config() function was treating the PCRE_MATCH_LIMIT and |
143 |
|
PCRE_MATCH_LIMIT_RECURSION values as ints, when they should be long ints. |
144 |
|
|
145 |
|
4. The pcregrep documentation said spaces were inserted as well as colons (or |
146 |
|
hyphens) following file names and line numbers when outputting matching |
147 |
|
lines. This is not true; no spaces are inserted. I have also clarified the |
148 |
|
wording for the --colour (or --color) option. |
149 |
|
|
150 |
|
5. In pcregrep, when --colour was used with -o, the list of matching strings |
151 |
|
was not coloured; this is different to GNU grep, so I have changed it to be |
152 |
|
the same. |
153 |
|
|
154 |
|
6. When --colo(u)r was used in pcregrep, only the first matching substring in |
155 |
|
each matching line was coloured. Now it goes on to look for further matches |
156 |
|
of any of the test patterns, which is the same behaviour as GNU grep. |
157 |
|
|
158 |
|
7. A pattern that could match an empty string could cause pcregrep to loop; it |
159 |
|
doesn't make sense to accept an empty string match in pcregrep, so I have |
160 |
|
locked it out (using PCRE's PCRE_NOTEMPTY option). By experiment, this |
161 |
|
seems to be how GNU grep behaves. |
162 |
|
|
163 |
|
8. The pattern (?(?=.*b)b|^) was incorrectly compiled as "match must be at |
164 |
|
start or after a newline", because the conditional assertion was not being |
165 |
|
correctly handled. The rule now is that both the assertion and what follows |
166 |
|
in the first alternative must satisfy the test. |
167 |
|
|
168 |
|
9. If auto-callout was enabled in a pattern with a conditional group whose |
169 |
|
condition was an assertion, PCRE could crash during matching, both with |
170 |
|
pcre_exec() and pcre_dfa_exec(). |
171 |
|
|
172 |
|
10. The PCRE_DOLLAR_ENDONLY option was not working when pcre_dfa_exec() was |
173 |
|
used for matching. |
174 |
|
|
175 |
|
11. Unicode property support in character classes was not working for |
176 |
|
characters (bytes) greater than 127 when not in UTF-8 mode. |
177 |
|
|
178 |
|
12. Added the -M command line option to pcretest. |
179 |
|
|
180 |
|
14. Added the non-standard REG_NOTEMPTY option to the POSIX interface. |
181 |
|
|
182 |
|
15. Added the PCRE_NO_START_OPTIMIZE match-time option. |
183 |
|
|
184 |
|
16. Added comments and documentation about mis-use of no_arg in the C++ |
185 |
|
wrapper. |
186 |
|
|
187 |
|
17. Implemented support for UTF-8 encoding in EBCDIC environments, a patch |
188 |
|
from Martin Jerabek that uses macro names for all relevant character and |
189 |
|
string constants. |
190 |
|
|
191 |
|
18. Added to pcre_internal.h two configuration checks: (a) If both EBCDIC and |
192 |
|
SUPPORT_UTF8 are set, give an error; (b) If SUPPORT_UCP is set without |
193 |
|
SUPPORT_UTF8, define SUPPORT_UTF8. The "configure" script handles both of |
194 |
|
these, but not everybody uses configure. |
195 |
|
|
196 |
|
19. A conditional group that had only one branch was not being correctly |
197 |
|
recognized as an item that could match an empty string. This meant that an |
198 |
|
enclosing group might also not be so recognized, causing infinite looping |
199 |
|
(and probably a segfault) for patterns such as ^"((?(?=[a])[^"])|b)*"$ |
200 |
|
with the subject "ab", where knowledge that the repeated group can match |
201 |
|
nothing is needed in order to break the loop. |
202 |
|
|
203 |
|
20. If a pattern that was compiled with callouts was matched using pcre_dfa_ |
204 |
|
exec(), but without supplying a callout function, matching went wrong. |
205 |
|
|
206 |
|
21. If PCRE_ERROR_MATCHLIMIT occurred during a recursion, there was a memory |
207 |
|
leak if the size of the offset vector was greater than 30. When the vector |
208 |
|
is smaller, the saved offsets during recursion go onto a local stack |
209 |
|
vector, but for larger vectors malloc() is used. It was failing to free |
210 |
|
when the recursion yielded PCRE_ERROR_MATCH_LIMIT (or any other "abnormal" |
211 |
|
error, in fact). |
212 |
|
|
213 |
|
22. There was a missing #ifdef SUPPORT_UTF8 round one of the variables in the |
214 |
|
heapframe that is used only when UTF-8 support is enabled. This caused no |
215 |
|
problem, but was untidy. |
216 |
|
|
217 |
|
23. Steven Van Ingelgem's patch to CMakeLists.txt to change the name |
218 |
|
CMAKE_BINARY_DIR to PROJECT_BINARY_DIR so that it works when PCRE is |
219 |
|
included within another project. |
220 |
|
|
221 |
|
24. Steven Van Ingelgem's patches to add more options to the CMake support, |
222 |
|
slightly modified by me: |
223 |
|
|
224 |
|
(a) PCRE_BUILD_TESTS can be set OFF not to build the tests, including |
225 |
|
not building pcregrep. |
226 |
|
|
227 |
|
(b) PCRE_BUILD_PCREGREP can be see OFF not to build pcregrep, but only |
228 |
|
if PCRE_BUILD_TESTS is also set OFF, because the tests use pcregrep. |
229 |
|
|
230 |
|
25. Forward references, both numeric and by name, in patterns that made use of |
231 |
|
duplicate group numbers, could behave incorrectly or give incorrect errors, |
232 |
|
because when scanning forward to find the reference group, PCRE was not |
233 |
|
taking into account the duplicate group numbers. A pattern such as |
234 |
|
^X(?3)(a)(?|(b)|(q))(Y) is an example. |
235 |
|
|
236 |
|
26. Changed a few more instances of "const unsigned char *" to USPTR, making |
237 |
|
the feature of a custom pointer more persuasive (as requested by a user). |
238 |
|
|
239 |
|
27. Wrapped the definitions of fileno and isatty for Windows, which appear in |
240 |
|
pcretest.c, inside #ifndefs, because it seems they are sometimes already |
241 |
|
pre-defined. |
242 |
|
|
243 |
|
28. Added support for (*UTF8) at the start of a pattern. |
244 |
|
|
245 |
|
29. Arrange for flags added by the "release type" setting in CMake to be shown |
246 |
|
in the configuration summary. |
247 |
|
|
248 |
|
|
249 |
|
Version 7.8 05-Sep-08 |
250 |
|
--------------------- |
251 |
|
|
252 |
|
1. Replaced UCP searching code with optimized version as implemented for Ad |
253 |
|
Muncher (http://www.admuncher.com/) by Peter Kankowski. This uses a two- |
254 |
|
stage table and inline lookup instead of a function, giving speed ups of 2 |
255 |
|
to 5 times on some simple patterns that I tested. Permission was given to |
256 |
|
distribute the MultiStage2.py script that generates the tables (it's not in |
257 |
|
the tarball, but is in the Subversion repository). |
258 |
|
|
259 |
|
2. Updated the Unicode datatables to Unicode 5.1.0. This adds yet more |
260 |
|
scripts. |
261 |
|
|
262 |
|
3. Change 12 for 7.7 introduced a bug in pcre_study() when a pattern contained |
263 |
|
a group with a zero qualifier. The result of the study could be incorrect, |
264 |
|
or the function might crash, depending on the pattern. |
265 |
|
|
266 |
|
4. Caseless matching was not working for non-ASCII characters in back |
267 |
|
references. For example, /(\x{de})\1/8i was not matching \x{de}\x{fe}. |
268 |
|
It now works when Unicode Property Support is available. |
269 |
|
|
270 |
|
5. In pcretest, an escape such as \x{de} in the data was always generating |
271 |
|
a UTF-8 string, even in non-UTF-8 mode. Now it generates a single byte in |
272 |
|
non-UTF-8 mode. If the value is greater than 255, it gives a warning about |
273 |
|
truncation. |
274 |
|
|
275 |
|
6. Minor bugfix in pcrecpp.cc (change "" == ... to NULL == ...). |
276 |
|
|
277 |
|
7. Added two (int) casts to pcregrep when printing the difference of two |
278 |
|
pointers, in case they are 64-bit values. |
279 |
|
|
280 |
|
8. Added comments about Mac OS X stack usage to the pcrestack man page and to |
281 |
|
test 2 if it fails. |
282 |
|
|
283 |
|
9. Added PCRE_CALL_CONVENTION just before the names of all exported functions, |
284 |
|
and a #define of that name to empty if it is not externally set. This is to |
285 |
|
allow users of MSVC to set it if necessary. |
286 |
|
|
287 |
|
10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from |
288 |
|
the convenience functions in the pcre_get.c source file. |
289 |
|
|
290 |
|
11. An option change at the start of a pattern that had top-level alternatives |
291 |
|
could cause overwriting and/or a crash. This command provoked a crash in |
292 |
|
some environments: |
293 |
|
|
294 |
|
printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest |
295 |
|
|
296 |
|
This potential security problem was recorded as CVE-2008-2371. |
297 |
|
|
298 |
|
12. For a pattern where the match had to start at the beginning or immediately |
299 |
|
after a newline (e.g /.*anything/ without the DOTALL flag), pcre_exec() and |
300 |
|
pcre_dfa_exec() could read past the end of the passed subject if there was |
301 |
|
no match. To help with detecting such bugs (e.g. with valgrind), I modified |
302 |
|
pcretest so that it places the subject at the end of its malloc-ed buffer. |
303 |
|
|
304 |
|
13. The change to pcretest in 12 above threw up a couple more cases when pcre_ |
305 |
|
exec() might read past the end of the data buffer in UTF-8 mode. |
306 |
|
|
307 |
|
14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and |
308 |
|
the data contained the byte 0x85 as part of a UTF-8 character within its |
309 |
|
first line. This applied both to normal and DFA matching. |
310 |
|
|
311 |
|
15. Lazy qualifiers were not working in some cases in UTF-8 mode. For example, |
312 |
|
/^[^d]*?$/8 failed to match "abc". |
313 |
|
|
314 |
|
16. Added a missing copyright notice to pcrecpp_internal.h. |
315 |
|
|
316 |
|
17. Make it more clear in the documentation that values returned from |
317 |
|
pcre_exec() in ovector are byte offsets, not character counts. |
318 |
|
|
319 |
|
18. Tidied a few places to stop certain compilers from issuing warnings. |
320 |
|
|
321 |
|
19. Updated the Virtual Pascal + BCC files to compile the latest v7.7, as |
322 |
|
supplied by Stefan Weber. I made a further small update for 7.8 because |
323 |
|
there is a change of source arrangements: the pcre_searchfuncs.c module is |
324 |
|
replaced by pcre_ucd.c. |
325 |
|
|
326 |
|
|
327 |
|
Version 7.7 07-May-08 |
328 |
|
--------------------- |
329 |
|
|
330 |
|
1. Applied Craig's patch to sort out a long long problem: "If we can't convert |
331 |
|
a string to a long long, pretend we don't even have a long long." This is |
332 |
|
done by checking for the strtoq, strtoll, and _strtoi64 functions. |
333 |
|
|
334 |
|
2. Applied Craig's patch to pcrecpp.cc to restore ABI compatibility with |
335 |
|
pre-7.6 versions, which defined a global no_arg variable instead of putting |
336 |
|
it in the RE class. (See also #8 below.) |
337 |
|
|
338 |
|
3. Remove a line of dead code, identified by coverity and reported by Nuno |
339 |
|
Lopes. |
340 |
|
|
341 |
|
4. Fixed two related pcregrep bugs involving -r with --include or --exclude: |
342 |
|
|
343 |
|
(1) The include/exclude patterns were being applied to the whole pathnames |
344 |
|
of files, instead of just to the final components. |
345 |
|
|
346 |
|
(2) If there was more than one level of directory, the subdirectories were |
347 |
|
skipped unless they satisfied the include/exclude conditions. This is |
348 |
|
inconsistent with GNU grep (and could even be seen as contrary to the |
349 |
|
pcregrep specification - which I improved to make it absolutely clear). |
350 |
|
The action now is always to scan all levels of directory, and just |
351 |
|
apply the include/exclude patterns to regular files. |
352 |
|
|
353 |
|
5. Added the --include_dir and --exclude_dir patterns to pcregrep, and used |
354 |
|
--exclude_dir in the tests to avoid scanning .svn directories. |
355 |
|
|
356 |
|
6. Applied Craig's patch to the QuoteMeta function so that it escapes the |
357 |
|
NUL character as backslash + 0 rather than backslash + NUL, because PCRE |
358 |
|
doesn't support NULs in patterns. |
359 |
|
|
360 |
|
7. Added some missing "const"s to declarations of static tables in |
361 |
|
pcre_compile.c and pcre_dfa_exec.c. |
362 |
|
|
363 |
|
8. Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was |
364 |
|
caused by fix #2 above. (Subsequently also a second patch to fix the |
365 |
|
first patch. And a third patch - this was a messy problem.) |
366 |
|
|
367 |
|
9. Applied Craig's patch to remove the use of push_back(). |
368 |
|
|
369 |
|
10. Applied Alan Lehotsky's patch to add REG_STARTEND support to the POSIX |
370 |
|
matching function regexec(). |
371 |
|
|
372 |
|
11. Added support for the Oniguruma syntax \g<name>, \g<n>, \g'name', \g'n', |
373 |
|
which, however, unlike Perl's \g{...}, are subroutine calls, not back |
374 |
|
references. PCRE supports relative numbers with this syntax (I don't think |
375 |
|
Oniguruma does). |
376 |
|
|
377 |
|
12. Previously, a group with a zero repeat such as (...){0} was completely |
378 |
|
omitted from the compiled regex. However, this means that if the group |
379 |
|
was called as a subroutine from elsewhere in the pattern, things went wrong |
380 |
|
(an internal error was given). Such groups are now left in the compiled |
381 |
|
pattern, with a new opcode that causes them to be skipped at execution |
382 |
|
time. |
383 |
|
|
384 |
|
13. Added the PCRE_JAVASCRIPT_COMPAT option. This makes the following changes |
385 |
|
to the way PCRE behaves: |
386 |
|
|
387 |
|
(a) A lone ] character is dis-allowed (Perl treats it as data). |
388 |
|
|
389 |
|
(b) A back reference to an unmatched subpattern matches an empty string |
390 |
|
(Perl fails the current match path). |
391 |
|
|
392 |
|
(c) A data ] in a character class must be notated as \] because if the |
393 |
|
first data character in a class is ], it defines an empty class. (In |
394 |
|
Perl it is not possible to have an empty class.) The empty class [] |
395 |
|
never matches; it forces failure and is equivalent to (*FAIL) or (?!). |
396 |
|
The negative empty class [^] matches any one character, independently |
397 |
|
of the DOTALL setting. |
398 |
|
|
399 |
|
14. A pattern such as /(?2)[]a()b](abc)/ which had a forward reference to a |
400 |
|
non-existent subpattern following a character class starting with ']' and |
401 |
|
containing () gave an internal compiling error instead of "reference to |
402 |
|
non-existent subpattern". Fortunately, when the pattern did exist, the |
403 |
|
compiled code was correct. (When scanning forwards to check for the |
404 |
|
existencd of the subpattern, it was treating the data ']' as terminating |
405 |
|
the class, so got the count wrong. When actually compiling, the reference |
406 |
|
was subsequently set up correctly.) |
407 |
|
|
408 |
|
15. The "always fail" assertion (?!) is optimzed to (*FAIL) by pcre_compile; |
409 |
|
it was being rejected as not supported by pcre_dfa_exec(), even though |
410 |
|
other assertions are supported. I have made pcre_dfa_exec() support |
411 |
|
(*FAIL). |
412 |
|
|
413 |
|
16. The implementation of 13c above involved the invention of a new opcode, |
414 |
|
OP_ALLANY, which is like OP_ANY but doesn't check the /s flag. Since /s |
415 |
|
cannot be changed at match time, I realized I could make a small |
416 |
|
improvement to matching performance by compiling OP_ALLANY instead of |
417 |
|
OP_ANY for "." when DOTALL was set, and then removing the runtime tests |
418 |
|
on the OP_ANY path. |
419 |
|
|
420 |
|
17. Compiling pcretest on Windows with readline support failed without the |
421 |
|
following two fixes: (1) Make the unistd.h include conditional on |
422 |
|
HAVE_UNISTD_H; (2) #define isatty and fileno as _isatty and _fileno. |
423 |
|
|
424 |
|
18. Changed CMakeLists.txt and cmake/FindReadline.cmake to arrange for the |
425 |
|
ncurses library to be included for pcretest when ReadLine support is |
426 |
|
requested, but also to allow for it to be overridden. This patch came from |
427 |
|
Daniel Bergström. |
428 |
|
|
429 |
|
19. There was a typo in the file ucpinternal.h where f0_rangeflag was defined |
430 |
|
as 0x00f00000 instead of 0x00800000. Luckily, this would not have caused |
431 |
|
any errors with the current Unicode tables. Thanks to Peter Kankowski for |
432 |
|
spotting this. |
433 |
|
|
434 |
|
|
435 |
|
Version 7.6 28-Jan-08 |
436 |
|
--------------------- |
437 |
|
|
438 |
|
1. A character class containing a very large number of characters with |
439 |
|
codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer |
440 |
|
overflow. |
441 |
|
|
442 |
|
2. Patch to cut out the "long long" test in pcrecpp_unittest when |
443 |
|
HAVE_LONG_LONG is not defined. |
444 |
|
|
445 |
|
3. Applied Christian Ehrlicher's patch to update the CMake build files to |
446 |
|
bring them up to date and include new features. This patch includes: |
447 |
|
|
448 |
|
- Fixed PH's badly added libz and libbz2 support. |
449 |
|
- Fixed a problem with static linking. |
450 |
|
- Added pcredemo. [But later removed - see 7 below.] |
451 |
|
- Fixed dftables problem and added an option. |
452 |
|
- Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and |
453 |
|
HAVE_LONG_LONG. |
454 |
|
- Added readline support for pcretest. |
455 |
|
- Added an listing of the option settings after cmake has run. |
456 |
|
|
457 |
|
4. A user submitted a patch to Makefile that makes it easy to create |
458 |
|
"pcre.dll" under mingw when using Configure/Make. I added stuff to |
459 |
|
Makefile.am that cause it to include this special target, without |
460 |
|
affecting anything else. Note that the same mingw target plus all |
461 |
|
the other distribution libraries and programs are now supported |
462 |
|
when configuring with CMake (see 6 below) instead of with |
463 |
|
Configure/Make. |
464 |
|
|
465 |
|
5. Applied Craig's patch that moves no_arg into the RE class in the C++ code. |
466 |
|
This is an attempt to solve the reported problem "pcrecpp::no_arg is not |
467 |
|
exported in the Windows port". It has not yet been confirmed that the patch |
468 |
|
solves the problem, but it does no harm. |
469 |
|
|
470 |
|
6. Applied Sheri's patch to CMakeLists.txt to add NON_STANDARD_LIB_PREFIX and |
471 |
|
NON_STANDARD_LIB_SUFFIX for dll names built with mingw when configured |
472 |
|
with CMake, and also correct the comment about stack recursion. |
473 |
|
|
474 |
|
7. Remove the automatic building of pcredemo from the ./configure system and |
475 |
|
from CMakeLists.txt. The whole idea of pcredemo.c is that it is an example |
476 |
|
of a program that users should build themselves after PCRE is installed, so |
477 |
|
building it automatically is not really right. What is more, it gave |
478 |
|
trouble in some build environments. |
479 |
|
|
480 |
|
8. Further tidies to CMakeLists.txt from Sheri and Christian. |
481 |
|
|
482 |
|
|
483 |
|
Version 7.5 10-Jan-08 |
484 |
|
--------------------- |
485 |
|
|
486 |
|
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
487 |
|
values in parens when parsing an RE using the C++ wrapper." |
488 |
|
|
489 |
|
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
490 |
|
Characters greater than 255 were excluded from the class instead of being |
491 |
|
included. |
492 |
|
|
493 |
|
3. The same bug as (2) above applied to negated POSIX classes such as |
494 |
|
[:^space:]. |
495 |
|
|
496 |
|
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
497 |
|
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
498 |
|
I have changed it. |
499 |
|
|
500 |
|
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
501 |
|
first named subpattern) and a construct such as (?&a) would reference the |
502 |
|
first named subpattern whose name started with "a" (in other words, the |
503 |
|
length check was missing). Both these problems are fixed. "Subpattern name |
504 |
|
expected" is now given for (?&) (a zero-length name), and this patch also |
505 |
|
makes it give the same error for \k'' (previously it complained that that |
506 |
|
was a reference to a non-existent subpattern). |
507 |
|
|
508 |
|
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
509 |
|
this is right because (?- can be followed by option settings as well as by |
510 |
|
digits. I have, however, made the messages clearer. |
511 |
|
|
512 |
|
7. Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns |
513 |
|
than the number used in the conditional) now cause a compile-time error. |
514 |
|
This is actually not compatible with Perl, which accepts such patterns, but |
515 |
|
treats the conditional as always being FALSE (as PCRE used to), but it |
516 |
|
seems to me that giving a diagnostic is better. |
517 |
|
|
518 |
|
8. Change "alphameric" to the more common word "alphanumeric" in comments |
519 |
|
and messages. |
520 |
|
|
521 |
|
9. Fix two occurrences of "backslash" in comments that should have been |
522 |
|
"backspace". |
523 |
|
|
524 |
|
10. Remove two redundant lines of code that can never be obeyed (their function |
525 |
|
was moved elsewhere). |
526 |
|
|
527 |
|
11. The program that makes PCRE's Unicode character property table had a bug |
528 |
|
which caused it to generate incorrect table entries for sequences of |
529 |
|
characters that have the same character type, but are in different scripts. |
530 |
|
It amalgamated them into a single range, with the script of the first of |
531 |
|
them. In other words, some characters were in the wrong script. There were |
532 |
|
thirteen such cases, affecting characters in the following ranges: |
533 |
|
|
534 |
|
U+002b0 - U+002c1 |
535 |
|
U+0060c - U+0060d |
536 |
|
U+0061e - U+00612 |
537 |
|
U+0064b - U+0065e |
538 |
|
U+0074d - U+0076d |
539 |
|
U+01800 - U+01805 |
540 |
|
U+01d00 - U+01d77 |
541 |
|
U+01d9b - U+01dbf |
542 |
|
U+0200b - U+0200f |
543 |
|
U+030fc - U+030fe |
544 |
|
U+03260 - U+0327f |
545 |
|
U+0fb46 - U+0fbb1 |
546 |
|
U+10450 - U+1049d |
547 |
|
|
548 |
|
12. The -o option (show only the matching part of a line) for pcregrep was not |
549 |
|
compatible with GNU grep in that, if there was more than one match in a |
550 |
|
line, it showed only the first of them. It now behaves in the same way as |
551 |
|
GNU grep. |
552 |
|
|
553 |
|
13. If the -o and -v options were combined for pcregrep, it printed a blank |
554 |
|
line for every non-matching line. GNU grep prints nothing, and pcregrep now |
555 |
|
does the same. The return code can be used to tell if there were any |
556 |
|
non-matching lines. |
557 |
|
|
558 |
|
14. Added --file-offsets and --line-offsets to pcregrep. |
559 |
|
|
560 |
|
15. The pattern (?=something)(?R) was not being diagnosed as a potentially |
561 |
|
infinitely looping recursion. The bug was that positive lookaheads were not |
562 |
|
being skipped when checking for a possible empty match (negative lookaheads |
563 |
|
and both kinds of lookbehind were skipped). |
564 |
|
|
565 |
|
16. Fixed two typos in the Windows-only code in pcregrep.c, and moved the |
566 |
|
inclusion of <windows.h> to before rather than after the definition of |
567 |
|
INVALID_FILE_ATTRIBUTES (patch from David Byron). |
568 |
|
|
569 |
|
17. Specifying a possessive quantifier with a specific limit for a Unicode |
570 |
|
character property caused pcre_compile() to compile bad code, which led at |
571 |
|
runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this |
572 |
|
are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that |
573 |
|
caused the error; without that there was no problem. |
574 |
|
|
575 |
|
18. Added --enable-pcregrep-libz and --enable-pcregrep-libbz2. |
576 |
|
|
577 |
|
19. Added --enable-pcretest-libreadline. |
578 |
|
|
579 |
|
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
580 |
|
RE::GlobalReplace(). As a result, the number of replacements returned was |
581 |
|
double what it should be. I removed one of the increments, but Craig sent a |
582 |
|
later patch that removed the other one (the right fix) and added unit tests |
583 |
|
that check the return values (which was not done before). |
584 |
|
|
585 |
|
21. Several CMake things: |
586 |
|
|
587 |
|
(1) Arranged that, when cmake is used on Unix, the libraries end up with |
588 |
|
the names libpcre and libpcreposix, not just pcre and pcreposix. |
589 |
|
|
590 |
|
(2) The above change means that pcretest and pcregrep are now correctly |
591 |
|
linked with the newly-built libraries, not previously installed ones. |
592 |
|
|
593 |
|
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
594 |
|
|
595 |
|
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
596 |
|
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
597 |
|
UTF-8 newline character). The key issue is that the pattern starts .*; |
598 |
|
this means that the match must be either at the beginning, or after a |
599 |
|
newline. The bug was in the code for advancing after a failed match and |
600 |
|
checking that the new position followed a newline. It was not taking |
601 |
|
account of UTF-8 characters correctly. |
602 |
|
|
603 |
|
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
604 |
|
character classes. PCRE was not treating the sequence [:...:] as a |
605 |
|
character class unless the ... were all letters. Perl, however, seems to |
606 |
|
allow any characters between [: and :], though of course it rejects as |
607 |
|
unknown any "names" that contain non-letters, because all the known class |
608 |
|
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
609 |
|
for example, whereas PCRE did not - it did not recognize a POSIX character |
610 |
|
class. This seemed a bit dangerous, so the code has been changed to be |
611 |
|
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
612 |
|
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
613 |
|
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
614 |
|
Perl does, and where it didn't before. |
615 |
|
|
616 |
|
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
617 |
|
Windows environments %n is disabled by default. |
618 |
|
|
619 |
|
|
620 |
|
Version 7.4 21-Sep-07 |
621 |
--------------------- |
--------------------- |
622 |
|
|
623 |
1. Change 7.3/28 was implemented for classes by looking at the bitmap. This |
1. Change 7.3/28 was implemented for classes by looking at the bitmap. This |
649 |
|
|
650 |
7. Added macro for snprintf to pcrecpp_unittest.cc and also for strtoll and |
7. Added macro for snprintf to pcrecpp_unittest.cc and also for strtoll and |
651 |
strtoull to pcrecpp.cc to select the available functions in WIN32 when the |
strtoull to pcrecpp.cc to select the available functions in WIN32 when the |
652 |
windows.h file is present (where different names are used). |
windows.h file is present (where different names are used). [This was |
653 |
|
reversed later after testing - see 16 below.] |
654 |
|
|
655 |
8. Changed all #include <config.h> to #include "config.h". There were also |
8. Changed all #include <config.h> to #include "config.h". There were also |
656 |
some further <pcre.h> cases that I changed to "pcre.h". |
some further <pcre.h> cases that I changed to "pcre.h". |
679 |
|
|
680 |
13. Added checks for ANY and ANYCRLF to pcrecpp.cc where it previously |
13. Added checks for ANY and ANYCRLF to pcrecpp.cc where it previously |
681 |
checked only for CRLF. |
checked only for CRLF. |
682 |
|
|
683 |
14. Added casts to pcretest.c to avoid compiler warnings. |
14. Added casts to pcretest.c to avoid compiler warnings. |
684 |
|
|
685 |
|
15. Added Craig's patch to various pcrecpp modules to avoid compiler warnings. |
686 |
|
|
687 |
|
16. Added Craig's patch to remove the WINDOWS_H tests, that were not working, |
688 |
|
and instead check for _strtoi64 explicitly, and avoid the use of snprintf() |
689 |
|
entirely. This removes changes made in 7 above. |
690 |
|
|
691 |
|
17. The CMake files have been updated, and there is now more information about |
692 |
|
building with CMake in the NON-UNIX-USE document. |
693 |
|
|
694 |
|
|
695 |
Version 7.3 28-Aug-07 |
Version 7.3 28-Aug-07 |