1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
2 |
------------------ |
------------------ |
3 |
|
|
4 |
Version 7.5 31-Dec-07 |
Version 8.0 02 Jul-08 |
5 |
|
--------------------- |
6 |
|
|
7 |
|
1. Replaced UCP searching code with optimized version as implemented for Ad |
8 |
|
Muncher (http://www.admuncher.com/) by Peter Kankowski. This uses a two- |
9 |
|
stage table and inline lookup instead of a function, giving speed ups of 2 |
10 |
|
to 5 times on some simple patterns that I tested. Permission was given to |
11 |
|
distribute the MultiStage2.py script that generates the tables (it's not in |
12 |
|
the tarball, but is in the Subversion repository). |
13 |
|
|
14 |
|
2. Updated the Unicode datatables to Unicode 5.1.0. This adds yet more |
15 |
|
scripts. |
16 |
|
|
17 |
|
3. Change 12 for 7.7 introduced a bug in pcre_study() when a pattern contained |
18 |
|
a group with a zero qualifier. The result of the study could be incorrect, |
19 |
|
or the function might crash, depending on the pattern. |
20 |
|
|
21 |
|
4. Caseless matching was not working for non-ASCII characters in back |
22 |
|
references. For example, /(\x{de})\1/8i was not matching \x{de}\x{fe}. |
23 |
|
It now works when Unicode Property Support is available. |
24 |
|
|
25 |
|
5. In pcretest, an escape such as \x{de} in the data was always generating |
26 |
|
a UTF-8 string, even in non-UTF-8 mode. Now it generates a single byte in |
27 |
|
non-UTF-8 mode. If the value is greater than 255, it gives a warning about |
28 |
|
truncation. |
29 |
|
|
30 |
|
6. Minor bugfix in pcrecpp.cc (change "" == ... to NULL == ...). |
31 |
|
|
32 |
|
7. Added two (int) casts to pcregrep when printing the difference of two |
33 |
|
pointers, in case they are 64-bit values. |
34 |
|
|
35 |
|
8. Added comments about Mac OS X stack usage to the pcrestack man page and to |
36 |
|
test 2 if it fails. |
37 |
|
|
38 |
|
9. Added PCRE_CALL_CONVENTION just before the names of all exported functions, |
39 |
|
and a #define of that name to empty if it is not externally set. This is to |
40 |
|
allow users of MSVC to set it if necessary. |
41 |
|
|
42 |
|
10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from |
43 |
|
the convenience functions in the pcre_get.c source file. |
44 |
|
|
45 |
|
11. An option change at the start of a pattern that had top-level alternatives |
46 |
|
could cause overwriting and/or a crash. This command provoked a crash in |
47 |
|
some environments: |
48 |
|
|
49 |
|
printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest |
50 |
|
|
51 |
|
This potential security problem was recorded as CVE-2008-2371. |
52 |
|
|
53 |
|
12. For a pattern where the match had to start at the beginning or immediately |
54 |
|
after a newline (e.g /.*anything/ without the DOTALL flag), pcre_exec() and |
55 |
|
pcre_dfa_exec() could read past the end of the passed subject if there was |
56 |
|
no match. To help with detecting such bugs (e.g. with valgrind), I modified |
57 |
|
pcretest so that it places the subject at the end of its malloc-ed buffer. |
58 |
|
|
59 |
|
13. The change to pcretest in 12 above threw up a couple more cases when pcre_ |
60 |
|
exec() might read past the end of the data buffer in UTF-8 mode. |
61 |
|
|
62 |
|
14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and |
63 |
|
the data contained the byte 0x85 as part of a UTF-8 character within its |
64 |
|
first line. This applied both to normal and DFA matching. |
65 |
|
|
66 |
|
|
67 |
|
Version 7.7 07-May-08 |
68 |
|
--------------------- |
69 |
|
|
70 |
|
1. Applied Craig's patch to sort out a long long problem: "If we can't convert |
71 |
|
a string to a long long, pretend we don't even have a long long." This is |
72 |
|
done by checking for the strtoq, strtoll, and _strtoi64 functions. |
73 |
|
|
74 |
|
2. Applied Craig's patch to pcrecpp.cc to restore ABI compatibility with |
75 |
|
pre-7.6 versions, which defined a global no_arg variable instead of putting |
76 |
|
it in the RE class. (See also #8 below.) |
77 |
|
|
78 |
|
3. Remove a line of dead code, identified by coverity and reported by Nuno |
79 |
|
Lopes. |
80 |
|
|
81 |
|
4. Fixed two related pcregrep bugs involving -r with --include or --exclude: |
82 |
|
|
83 |
|
(1) The include/exclude patterns were being applied to the whole pathnames |
84 |
|
of files, instead of just to the final components. |
85 |
|
|
86 |
|
(2) If there was more than one level of directory, the subdirectories were |
87 |
|
skipped unless they satisfied the include/exclude conditions. This is |
88 |
|
inconsistent with GNU grep (and could even be seen as contrary to the |
89 |
|
pcregrep specification - which I improved to make it absolutely clear). |
90 |
|
The action now is always to scan all levels of directory, and just |
91 |
|
apply the include/exclude patterns to regular files. |
92 |
|
|
93 |
|
5. Added the --include_dir and --exclude_dir patterns to pcregrep, and used |
94 |
|
--exclude_dir in the tests to avoid scanning .svn directories. |
95 |
|
|
96 |
|
6. Applied Craig's patch to the QuoteMeta function so that it escapes the |
97 |
|
NUL character as backslash + 0 rather than backslash + NUL, because PCRE |
98 |
|
doesn't support NULs in patterns. |
99 |
|
|
100 |
|
7. Added some missing "const"s to declarations of static tables in |
101 |
|
pcre_compile.c and pcre_dfa_exec.c. |
102 |
|
|
103 |
|
8. Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was |
104 |
|
caused by fix #2 above. (Subsequently also a second patch to fix the |
105 |
|
first patch. And a third patch - this was a messy problem.) |
106 |
|
|
107 |
|
9. Applied Craig's patch to remove the use of push_back(). |
108 |
|
|
109 |
|
10. Applied Alan Lehotsky's patch to add REG_STARTEND support to the POSIX |
110 |
|
matching function regexec(). |
111 |
|
|
112 |
|
11. Added support for the Oniguruma syntax \g<name>, \g<n>, \g'name', \g'n', |
113 |
|
which, however, unlike Perl's \g{...}, are subroutine calls, not back |
114 |
|
references. PCRE supports relative numbers with this syntax (I don't think |
115 |
|
Oniguruma does). |
116 |
|
|
117 |
|
12. Previously, a group with a zero repeat such as (...){0} was completely |
118 |
|
omitted from the compiled regex. However, this means that if the group |
119 |
|
was called as a subroutine from elsewhere in the pattern, things went wrong |
120 |
|
(an internal error was given). Such groups are now left in the compiled |
121 |
|
pattern, with a new opcode that causes them to be skipped at execution |
122 |
|
time. |
123 |
|
|
124 |
|
13. Added the PCRE_JAVASCRIPT_COMPAT option. This makes the following changes |
125 |
|
to the way PCRE behaves: |
126 |
|
|
127 |
|
(a) A lone ] character is dis-allowed (Perl treats it as data). |
128 |
|
|
129 |
|
(b) A back reference to an unmatched subpattern matches an empty string |
130 |
|
(Perl fails the current match path). |
131 |
|
|
132 |
|
(c) A data ] in a character class must be notated as \] because if the |
133 |
|
first data character in a class is ], it defines an empty class. (In |
134 |
|
Perl it is not possible to have an empty class.) The empty class [] |
135 |
|
never matches; it forces failure and is equivalent to (*FAIL) or (?!). |
136 |
|
The negative empty class [^] matches any one character, independently |
137 |
|
of the DOTALL setting. |
138 |
|
|
139 |
|
14. A pattern such as /(?2)[]a()b](abc)/ which had a forward reference to a |
140 |
|
non-existent subpattern following a character class starting with ']' and |
141 |
|
containing () gave an internal compiling error instead of "reference to |
142 |
|
non-existent subpattern". Fortunately, when the pattern did exist, the |
143 |
|
compiled code was correct. (When scanning forwards to check for the |
144 |
|
existencd of the subpattern, it was treating the data ']' as terminating |
145 |
|
the class, so got the count wrong. When actually compiling, the reference |
146 |
|
was subsequently set up correctly.) |
147 |
|
|
148 |
|
15. The "always fail" assertion (?!) is optimzed to (*FAIL) by pcre_compile; |
149 |
|
it was being rejected as not supported by pcre_dfa_exec(), even though |
150 |
|
other assertions are supported. I have made pcre_dfa_exec() support |
151 |
|
(*FAIL). |
152 |
|
|
153 |
|
16. The implementation of 13c above involved the invention of a new opcode, |
154 |
|
OP_ALLANY, which is like OP_ANY but doesn't check the /s flag. Since /s |
155 |
|
cannot be changed at match time, I realized I could make a small |
156 |
|
improvement to matching performance by compiling OP_ALLANY instead of |
157 |
|
OP_ANY for "." when DOTALL was set, and then removing the runtime tests |
158 |
|
on the OP_ANY path. |
159 |
|
|
160 |
|
17. Compiling pcretest on Windows with readline support failed without the |
161 |
|
following two fixes: (1) Make the unistd.h include conditional on |
162 |
|
HAVE_UNISTD_H; (2) #define isatty and fileno as _isatty and _fileno. |
163 |
|
|
164 |
|
18. Changed CMakeLists.txt and cmake/FindReadline.cmake to arrange for the |
165 |
|
ncurses library to be included for pcretest when ReadLine support is |
166 |
|
requested, but also to allow for it to be overridden. This patch came from |
167 |
|
Daniel Bergström. |
168 |
|
|
169 |
|
19. There was a typo in the file ucpinternal.h where f0_rangeflag was defined |
170 |
|
as 0x00f00000 instead of 0x00800000. Luckily, this would not have caused |
171 |
|
any errors with the current Unicode tables. Thanks to Peter Kankowski for |
172 |
|
spotting this. |
173 |
|
|
174 |
|
|
175 |
|
Version 7.6 28-Jan-08 |
176 |
|
--------------------- |
177 |
|
|
178 |
|
1. A character class containing a very large number of characters with |
179 |
|
codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer |
180 |
|
overflow. |
181 |
|
|
182 |
|
2. Patch to cut out the "long long" test in pcrecpp_unittest when |
183 |
|
HAVE_LONG_LONG is not defined. |
184 |
|
|
185 |
|
3. Applied Christian Ehrlicher's patch to update the CMake build files to |
186 |
|
bring them up to date and include new features. This patch includes: |
187 |
|
|
188 |
|
- Fixed PH's badly added libz and libbz2 support. |
189 |
|
- Fixed a problem with static linking. |
190 |
|
- Added pcredemo. [But later removed - see 7 below.] |
191 |
|
- Fixed dftables problem and added an option. |
192 |
|
- Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and |
193 |
|
HAVE_LONG_LONG. |
194 |
|
- Added readline support for pcretest. |
195 |
|
- Added an listing of the option settings after cmake has run. |
196 |
|
|
197 |
|
4. A user submitted a patch to Makefile that makes it easy to create |
198 |
|
"pcre.dll" under mingw when using Configure/Make. I added stuff to |
199 |
|
Makefile.am that cause it to include this special target, without |
200 |
|
affecting anything else. Note that the same mingw target plus all |
201 |
|
the other distribution libraries and programs are now supported |
202 |
|
when configuring with CMake (see 6 below) instead of with |
203 |
|
Configure/Make. |
204 |
|
|
205 |
|
5. Applied Craig's patch that moves no_arg into the RE class in the C++ code. |
206 |
|
This is an attempt to solve the reported problem "pcrecpp::no_arg is not |
207 |
|
exported in the Windows port". It has not yet been confirmed that the patch |
208 |
|
solves the problem, but it does no harm. |
209 |
|
|
210 |
|
6. Applied Sheri's patch to CMakeLists.txt to add NON_STANDARD_LIB_PREFIX and |
211 |
|
NON_STANDARD_LIB_SUFFIX for dll names built with mingw when configured |
212 |
|
with CMake, and also correct the comment about stack recursion. |
213 |
|
|
214 |
|
7. Remove the automatic building of pcredemo from the ./configure system and |
215 |
|
from CMakeLists.txt. The whole idea of pcredemo.c is that it is an example |
216 |
|
of a program that users should build themselves after PCRE is installed, so |
217 |
|
building it automatically is not really right. What is more, it gave |
218 |
|
trouble in some build environments. |
219 |
|
|
220 |
|
8. Further tidies to CMakeLists.txt from Sheri and Christian. |
221 |
|
|
222 |
|
|
223 |
|
Version 7.5 10-Jan-08 |
224 |
--------------------- |
--------------------- |
225 |
|
|
226 |
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
318 |
|
|
319 |
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
320 |
RE::GlobalReplace(). As a result, the number of replacements returned was |
RE::GlobalReplace(). As a result, the number of replacements returned was |
321 |
double what it should be. I have removed one of the increments. |
double what it should be. I removed one of the increments, but Craig sent a |
322 |
|
later patch that removed the other one (the right fix) and added unit tests |
323 |
|
that check the return values (which was not done before). |
324 |
|
|
325 |
21. Several CMake things: |
21. Several CMake things: |
326 |
|
|
331 |
linked with the newly-built libraries, not previously installed ones. |
linked with the newly-built libraries, not previously installed ones. |
332 |
|
|
333 |
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
334 |
|
|
335 |
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
336 |
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
337 |
UTF-8 newline character). The key issue is that the pattern starts .*; |
UTF-8 newline character). The key issue is that the pattern starts .*; |
338 |
this means that the match must be either at the beginning, or after a |
this means that the match must be either at the beginning, or after a |
339 |
newline. The bug was in the code for advancing after a failed match and |
newline. The bug was in the code for advancing after a failed match and |
340 |
checking that the new position followed a newline. It was not taking |
checking that the new position followed a newline. It was not taking |
341 |
account of UTF-8 characters correctly. |
account of UTF-8 characters correctly. |
342 |
|
|
343 |
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
344 |
character classes. PCRE was not treating the sequence [:...:] as a |
character classes. PCRE was not treating the sequence [:...:] as a |
345 |
character class unless the ... were all letters. Perl, however, seems to |
character class unless the ... were all letters. Perl, however, seems to |
346 |
allow any characters between [: and :], though of course it rejects as |
allow any characters between [: and :], though of course it rejects as |
347 |
unknown any "names" that contain non-letters, because all the known class |
unknown any "names" that contain non-letters, because all the known class |
348 |
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
349 |
for example, whereas PCRE did not - it did not recognize a POSIX character |
for example, whereas PCRE did not - it did not recognize a POSIX character |
350 |
class. This seemed a bit dangerous, so the code has been changed to be |
class. This seemed a bit dangerous, so the code has been changed to be |
351 |
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
352 |
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
353 |
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
354 |
Perl does, and where it didn't before. |
Perl does, and where it didn't before. |
355 |
|
|
356 |
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
357 |
Windows environments %n is disabled by default. |
Windows environments %n is disabled by default. |
358 |
|
|