1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
2 |
------------------ |
------------------ |
3 |
|
|
4 |
Version 7.1 05-Mar-07 |
Version 7.7 28-Apr-08 |
5 |
--------------------- |
--------------------- |
6 |
|
|
7 |
1. Applied Bob Rossi and Daniel G's patches to convert the build system to one |
1. Applied Craig's patch to sort out a long long problem: "If we can't convert |
8 |
that is more "standard", making use of automake and other autotools. There |
a string to a long long, pretend we don't even have a long long." This is |
9 |
|
done by checking for the strtoq, strtoll, and _strtoi64 functions. |
10 |
|
|
11 |
|
2. Applied Craig's patch to pcrecpp.cc to restore ABI compatibility with |
12 |
|
pre-7.6 versions, which defined a global no_arg variable instead of putting |
13 |
|
it in the RE class. (See also #8 below.) |
14 |
|
|
15 |
|
3. Remove a line of dead code, identified by coverity and reported by Nuno |
16 |
|
Lopes. |
17 |
|
|
18 |
|
4. Fixed two related pcregrep bugs involving -r with --include or --exclude: |
19 |
|
|
20 |
|
(1) The include/exclude patterns were being applied to the whole pathnames |
21 |
|
of files, instead of just to the final components. |
22 |
|
|
23 |
|
(2) If there was more than one level of directory, the subdirectories were |
24 |
|
skipped unless they satisfied the include/exclude conditions. This is |
25 |
|
inconsistent with GNU grep (and could even be seen as contrary to the |
26 |
|
pcregrep specification - which I improved to make it absolutely clear). |
27 |
|
The action now is always to scan all levels of directory, and just |
28 |
|
apply the include/exclude patterns to regular files. |
29 |
|
|
30 |
|
5. Added the --include_dir and --exclude_dir patterns to pcregrep, and used |
31 |
|
--exclude_dir in the tests to avoid scanning .svn directories. |
32 |
|
|
33 |
|
6. Applied Craig's patch to the QuoteMeta function so that it escapes the |
34 |
|
NUL character as backslash + 0 rather than backslash + NUL, because PCRE |
35 |
|
doesn't support NULs in patterns. |
36 |
|
|
37 |
|
7. Added some missing "const"s to declarations of static tables in |
38 |
|
pcre_compile.c and pcre_dfa_exec.c. |
39 |
|
|
40 |
|
8. Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was |
41 |
|
caused by fix #2 above. (Subsequently also a second patch to fix the |
42 |
|
first patch. And a third patch - this was a messy problem.) |
43 |
|
|
44 |
|
9. Applied Craig's patch to remove the use of push_back(). |
45 |
|
|
46 |
|
10. Applied Alan Lehotsky's patch to add REG_STARTEND support to the POSIX |
47 |
|
matching function regexec(). |
48 |
|
|
49 |
|
11. Added support for the Oniguruma syntax \g<name>, \g<n>, \g'name', \g'n', |
50 |
|
which, however, unlike Perl's \g{...}, are subroutine calls, not back |
51 |
|
references. PCRE supports relative numbers with this syntax (I don't think |
52 |
|
Oniguruma does). |
53 |
|
|
54 |
|
12. Previously, a group with a zero repeat such as (...){0} was completely |
55 |
|
omitted from the compiled regex. However, this means that if the group |
56 |
|
was called as a subroutine from elsewhere in the pattern, things went wrong |
57 |
|
(an internal error was given). Such groups are now left in the compiled |
58 |
|
pattern, with a new opcode that causes them to be skipped at execution |
59 |
|
time. |
60 |
|
|
61 |
|
13. Added the PCRE_JAVASCRIPT_COMPAT option. This makes the following changes |
62 |
|
to the way PCRE behaves: |
63 |
|
|
64 |
|
(a) A lone ] character is dis-allowed (Perl treats it as data). |
65 |
|
|
66 |
|
(b) A back reference to an unmatched subpattern matches an empty string |
67 |
|
(Perl fails the current match path). |
68 |
|
|
69 |
|
(c) A data ] in a character class must be notated as \] because if the |
70 |
|
first data character in a class is ], it defines an empty class. (In |
71 |
|
Perl it is not possible to have an empty class.) The empty class [] |
72 |
|
never matches; it forces failure and is equivalent to (*FAIL) or (?!). |
73 |
|
The negative empty class [^] matches any one character, independently |
74 |
|
of the DOTALL setting. |
75 |
|
|
76 |
|
14. A pattern such as /(?2)[]a()b](abc)/ which had a forward reference to a |
77 |
|
non-existent subpattern following a character class starting with ']' and |
78 |
|
containing () gave an internal compiling error instead of "reference to |
79 |
|
non-existent subpattern". Fortunately, when the pattern did exist, the |
80 |
|
compiled code was correct. (When scanning forwards to check for the |
81 |
|
existencd of the subpattern, it was treating the data ']' as terminating |
82 |
|
the class, so got the count wrong. When actually compiling, the reference |
83 |
|
was subsequently set up correctly.) |
84 |
|
|
85 |
|
15. The "always fail" assertion (?!) is optimzed to (*FAIL) by pcre_compile; |
86 |
|
it was being rejected as not supported by pcre_dfa_exec(), even though |
87 |
|
other assertions are supported. I have made pcre_dfa_exec() support |
88 |
|
(*FAIL). |
89 |
|
|
90 |
|
16. The implementation of 13c above involved the invention of a new opcode, |
91 |
|
OP_ALLANY, which is like OP_ANY but doesn't check the /s flag. Since /s |
92 |
|
cannot be changed at match time, I realized I could make a small |
93 |
|
improvement to matching performance by compiling OP_ALLANY instead of |
94 |
|
OP_ANY for "." when DOTALL was set, and then removing the runtime tests |
95 |
|
on the OP_ANY path. |
96 |
|
|
97 |
|
17. Compiling pcretest on Windows with readline support failed without the |
98 |
|
following two fixes: (1) Make the unistd.h include conditional on |
99 |
|
HAVE_UNISTD_H; (2) #define isatty and fileno as _isatty and _fileno. |
100 |
|
|
101 |
|
18. Changed CMakeLists.txt and cmake/FindReadline.cmake to arrange for the |
102 |
|
ncurses library to be included for pcretest when ReadLine support is |
103 |
|
requested, but also to allow for it to be overridden. This patch came from |
104 |
|
Daniel Bergström. |
105 |
|
|
106 |
|
|
107 |
|
Version 7.6 28-Jan-08 |
108 |
|
--------------------- |
109 |
|
|
110 |
|
1. A character class containing a very large number of characters with |
111 |
|
codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer |
112 |
|
overflow. |
113 |
|
|
114 |
|
2. Patch to cut out the "long long" test in pcrecpp_unittest when |
115 |
|
HAVE_LONG_LONG is not defined. |
116 |
|
|
117 |
|
3. Applied Christian Ehrlicher's patch to update the CMake build files to |
118 |
|
bring them up to date and include new features. This patch includes: |
119 |
|
|
120 |
|
- Fixed PH's badly added libz and libbz2 support. |
121 |
|
- Fixed a problem with static linking. |
122 |
|
- Added pcredemo. [But later removed - see 7 below.] |
123 |
|
- Fixed dftables problem and added an option. |
124 |
|
- Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and |
125 |
|
HAVE_LONG_LONG. |
126 |
|
- Added readline support for pcretest. |
127 |
|
- Added an listing of the option settings after cmake has run. |
128 |
|
|
129 |
|
4. A user submitted a patch to Makefile that makes it easy to create |
130 |
|
"pcre.dll" under mingw when using Configure/Make. I added stuff to |
131 |
|
Makefile.am that cause it to include this special target, without |
132 |
|
affecting anything else. Note that the same mingw target plus all |
133 |
|
the other distribution libraries and programs are now supported |
134 |
|
when configuring with CMake (see 6 below) instead of with |
135 |
|
Configure/Make. |
136 |
|
|
137 |
|
5. Applied Craig's patch that moves no_arg into the RE class in the C++ code. |
138 |
|
This is an attempt to solve the reported problem "pcrecpp::no_arg is not |
139 |
|
exported in the Windows port". It has not yet been confirmed that the patch |
140 |
|
solves the problem, but it does no harm. |
141 |
|
|
142 |
|
6. Applied Sheri's patch to CMakeLists.txt to add NON_STANDARD_LIB_PREFIX and |
143 |
|
NON_STANDARD_LIB_SUFFIX for dll names built with mingw when configured |
144 |
|
with CMake, and also correct the comment about stack recursion. |
145 |
|
|
146 |
|
7. Remove the automatic building of pcredemo from the ./configure system and |
147 |
|
from CMakeLists.txt. The whole idea of pcredemo.c is that it is an example |
148 |
|
of a program that users should build themselves after PCRE is installed, so |
149 |
|
building it automatically is not really right. What is more, it gave |
150 |
|
trouble in some build environments. |
151 |
|
|
152 |
|
8. Further tidies to CMakeLists.txt from Sheri and Christian. |
153 |
|
|
154 |
|
|
155 |
|
Version 7.5 10-Jan-08 |
156 |
|
--------------------- |
157 |
|
|
158 |
|
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
159 |
|
values in parens when parsing an RE using the C++ wrapper." |
160 |
|
|
161 |
|
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
162 |
|
Characters greater than 255 were excluded from the class instead of being |
163 |
|
included. |
164 |
|
|
165 |
|
3. The same bug as (2) above applied to negated POSIX classes such as |
166 |
|
[:^space:]. |
167 |
|
|
168 |
|
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
169 |
|
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
170 |
|
I have changed it. |
171 |
|
|
172 |
|
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
173 |
|
first named subpattern) and a construct such as (?&a) would reference the |
174 |
|
first named subpattern whose name started with "a" (in other words, the |
175 |
|
length check was missing). Both these problems are fixed. "Subpattern name |
176 |
|
expected" is now given for (?&) (a zero-length name), and this patch also |
177 |
|
makes it give the same error for \k'' (previously it complained that that |
178 |
|
was a reference to a non-existent subpattern). |
179 |
|
|
180 |
|
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
181 |
|
this is right because (?- can be followed by option settings as well as by |
182 |
|
digits. I have, however, made the messages clearer. |
183 |
|
|
184 |
|
7. Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns |
185 |
|
than the number used in the conditional) now cause a compile-time error. |
186 |
|
This is actually not compatible with Perl, which accepts such patterns, but |
187 |
|
treats the conditional as always being FALSE (as PCRE used to), but it |
188 |
|
seems to me that giving a diagnostic is better. |
189 |
|
|
190 |
|
8. Change "alphameric" to the more common word "alphanumeric" in comments |
191 |
|
and messages. |
192 |
|
|
193 |
|
9. Fix two occurrences of "backslash" in comments that should have been |
194 |
|
"backspace". |
195 |
|
|
196 |
|
10. Remove two redundant lines of code that can never be obeyed (their function |
197 |
|
was moved elsewhere). |
198 |
|
|
199 |
|
11. The program that makes PCRE's Unicode character property table had a bug |
200 |
|
which caused it to generate incorrect table entries for sequences of |
201 |
|
characters that have the same character type, but are in different scripts. |
202 |
|
It amalgamated them into a single range, with the script of the first of |
203 |
|
them. In other words, some characters were in the wrong script. There were |
204 |
|
thirteen such cases, affecting characters in the following ranges: |
205 |
|
|
206 |
|
U+002b0 - U+002c1 |
207 |
|
U+0060c - U+0060d |
208 |
|
U+0061e - U+00612 |
209 |
|
U+0064b - U+0065e |
210 |
|
U+0074d - U+0076d |
211 |
|
U+01800 - U+01805 |
212 |
|
U+01d00 - U+01d77 |
213 |
|
U+01d9b - U+01dbf |
214 |
|
U+0200b - U+0200f |
215 |
|
U+030fc - U+030fe |
216 |
|
U+03260 - U+0327f |
217 |
|
U+0fb46 - U+0fbb1 |
218 |
|
U+10450 - U+1049d |
219 |
|
|
220 |
|
12. The -o option (show only the matching part of a line) for pcregrep was not |
221 |
|
compatible with GNU grep in that, if there was more than one match in a |
222 |
|
line, it showed only the first of them. It now behaves in the same way as |
223 |
|
GNU grep. |
224 |
|
|
225 |
|
13. If the -o and -v options were combined for pcregrep, it printed a blank |
226 |
|
line for every non-matching line. GNU grep prints nothing, and pcregrep now |
227 |
|
does the same. The return code can be used to tell if there were any |
228 |
|
non-matching lines. |
229 |
|
|
230 |
|
14. Added --file-offsets and --line-offsets to pcregrep. |
231 |
|
|
232 |
|
15. The pattern (?=something)(?R) was not being diagnosed as a potentially |
233 |
|
infinitely looping recursion. The bug was that positive lookaheads were not |
234 |
|
being skipped when checking for a possible empty match (negative lookaheads |
235 |
|
and both kinds of lookbehind were skipped). |
236 |
|
|
237 |
|
16. Fixed two typos in the Windows-only code in pcregrep.c, and moved the |
238 |
|
inclusion of <windows.h> to before rather than after the definition of |
239 |
|
INVALID_FILE_ATTRIBUTES (patch from David Byron). |
240 |
|
|
241 |
|
17. Specifying a possessive quantifier with a specific limit for a Unicode |
242 |
|
character property caused pcre_compile() to compile bad code, which led at |
243 |
|
runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this |
244 |
|
are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that |
245 |
|
caused the error; without that there was no problem. |
246 |
|
|
247 |
|
18. Added --enable-pcregrep-libz and --enable-pcregrep-libbz2. |
248 |
|
|
249 |
|
19. Added --enable-pcretest-libreadline. |
250 |
|
|
251 |
|
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
252 |
|
RE::GlobalReplace(). As a result, the number of replacements returned was |
253 |
|
double what it should be. I removed one of the increments, but Craig sent a |
254 |
|
later patch that removed the other one (the right fix) and added unit tests |
255 |
|
that check the return values (which was not done before). |
256 |
|
|
257 |
|
21. Several CMake things: |
258 |
|
|
259 |
|
(1) Arranged that, when cmake is used on Unix, the libraries end up with |
260 |
|
the names libpcre and libpcreposix, not just pcre and pcreposix. |
261 |
|
|
262 |
|
(2) The above change means that pcretest and pcregrep are now correctly |
263 |
|
linked with the newly-built libraries, not previously installed ones. |
264 |
|
|
265 |
|
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
266 |
|
|
267 |
|
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
268 |
|
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
269 |
|
UTF-8 newline character). The key issue is that the pattern starts .*; |
270 |
|
this means that the match must be either at the beginning, or after a |
271 |
|
newline. The bug was in the code for advancing after a failed match and |
272 |
|
checking that the new position followed a newline. It was not taking |
273 |
|
account of UTF-8 characters correctly. |
274 |
|
|
275 |
|
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
276 |
|
character classes. PCRE was not treating the sequence [:...:] as a |
277 |
|
character class unless the ... were all letters. Perl, however, seems to |
278 |
|
allow any characters between [: and :], though of course it rejects as |
279 |
|
unknown any "names" that contain non-letters, because all the known class |
280 |
|
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
281 |
|
for example, whereas PCRE did not - it did not recognize a POSIX character |
282 |
|
class. This seemed a bit dangerous, so the code has been changed to be |
283 |
|
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
284 |
|
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
285 |
|
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
286 |
|
Perl does, and where it didn't before. |
287 |
|
|
288 |
|
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
289 |
|
Windows environments %n is disabled by default. |
290 |
|
|
291 |
|
|
292 |
|
Version 7.4 21-Sep-07 |
293 |
|
--------------------- |
294 |
|
|
295 |
|
1. Change 7.3/28 was implemented for classes by looking at the bitmap. This |
296 |
|
means that a class such as [\s] counted as "explicit reference to CR or |
297 |
|
LF". That isn't really right - the whole point of the change was to try to |
298 |
|
help when there was an actual mention of one of the two characters. So now |
299 |
|
the change happens only if \r or \n (or a literal CR or LF) character is |
300 |
|
encountered. |
301 |
|
|
302 |
|
2. The 32-bit options word was also used for 6 internal flags, but the numbers |
303 |
|
of both had grown to the point where there were only 3 bits left. |
304 |
|
Fortunately, there was spare space in the data structure, and so I have |
305 |
|
moved the internal flags into a new 16-bit field to free up more option |
306 |
|
bits. |
307 |
|
|
308 |
|
3. The appearance of (?J) at the start of a pattern set the DUPNAMES option, |
309 |
|
but did not set the internal JCHANGED flag - either of these is enough to |
310 |
|
control the way the "get" function works - but the PCRE_INFO_JCHANGED |
311 |
|
facility is supposed to tell if (?J) was ever used, so now (?J) at the |
312 |
|
start sets both bits. |
313 |
|
|
314 |
|
4. Added options (at build time, compile time, exec time) to change \R from |
315 |
|
matching any Unicode line ending sequence to just matching CR, LF, or CRLF. |
316 |
|
|
317 |
|
5. doc/pcresyntax.html was missing from the distribution. |
318 |
|
|
319 |
|
6. Put back the definition of PCRE_ERROR_NULLWSLIMIT, for backward |
320 |
|
compatibility, even though it is no longer used. |
321 |
|
|
322 |
|
7. Added macro for snprintf to pcrecpp_unittest.cc and also for strtoll and |
323 |
|
strtoull to pcrecpp.cc to select the available functions in WIN32 when the |
324 |
|
windows.h file is present (where different names are used). [This was |
325 |
|
reversed later after testing - see 16 below.] |
326 |
|
|
327 |
|
8. Changed all #include <config.h> to #include "config.h". There were also |
328 |
|
some further <pcre.h> cases that I changed to "pcre.h". |
329 |
|
|
330 |
|
9. When pcregrep was used with the --colour option, it missed the line ending |
331 |
|
sequence off the lines that it output. |
332 |
|
|
333 |
|
10. It was pointed out to me that arrays of string pointers cause lots of |
334 |
|
relocations when a shared library is dynamically loaded. A technique of |
335 |
|
using a single long string with a table of offsets can drastically reduce |
336 |
|
these. I have refactored PCRE in four places to do this. The result is |
337 |
|
dramatic: |
338 |
|
|
339 |
|
Originally: 290 |
340 |
|
After changing UCP table: 187 |
341 |
|
After changing error message table: 43 |
342 |
|
After changing table of "verbs" 36 |
343 |
|
After changing table of Posix names 22 |
344 |
|
|
345 |
|
Thanks to the folks working on Gregex for glib for this insight. |
346 |
|
|
347 |
|
11. --disable-stack-for-recursion caused compiling to fail unless -enable- |
348 |
|
unicode-properties was also set. |
349 |
|
|
350 |
|
12. Updated the tests so that they work when \R is defaulted to ANYCRLF. |
351 |
|
|
352 |
|
13. Added checks for ANY and ANYCRLF to pcrecpp.cc where it previously |
353 |
|
checked only for CRLF. |
354 |
|
|
355 |
|
14. Added casts to pcretest.c to avoid compiler warnings. |
356 |
|
|
357 |
|
15. Added Craig's patch to various pcrecpp modules to avoid compiler warnings. |
358 |
|
|
359 |
|
16. Added Craig's patch to remove the WINDOWS_H tests, that were not working, |
360 |
|
and instead check for _strtoi64 explicitly, and avoid the use of snprintf() |
361 |
|
entirely. This removes changes made in 7 above. |
362 |
|
|
363 |
|
17. The CMake files have been updated, and there is now more information about |
364 |
|
building with CMake in the NON-UNIX-USE document. |
365 |
|
|
366 |
|
|
367 |
|
Version 7.3 28-Aug-07 |
368 |
|
--------------------- |
369 |
|
|
370 |
|
1. In the rejigging of the build system that eventually resulted in 7.1, the |
371 |
|
line "#include <pcre.h>" was included in pcre_internal.h. The use of angle |
372 |
|
brackets there is not right, since it causes compilers to look for an |
373 |
|
installed pcre.h, not the version that is in the source that is being |
374 |
|
compiled (which of course may be different). I have changed it back to: |
375 |
|
|
376 |
|
#include "pcre.h" |
377 |
|
|
378 |
|
I have a vague recollection that the change was concerned with compiling in |
379 |
|
different directories, but in the new build system, that is taken care of |
380 |
|
by the VPATH setting the Makefile. |
381 |
|
|
382 |
|
2. The pattern .*$ when run in not-DOTALL UTF-8 mode with newline=any failed |
383 |
|
when the subject happened to end in the byte 0x85 (e.g. if the last |
384 |
|
character was \x{1ec5}). *Character* 0x85 is one of the "any" newline |
385 |
|
characters but of course it shouldn't be taken as a newline when it is part |
386 |
|
of another character. The bug was that, for an unlimited repeat of . in |
387 |
|
not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by |
388 |
|
characters when looking for a newline. |
389 |
|
|
390 |
|
3. A small performance improvement in the DOTALL UTF-8 mode .* case. |
391 |
|
|
392 |
|
4. Debugging: adjusted the names of opcodes for different kinds of parentheses |
393 |
|
in debug output. |
394 |
|
|
395 |
|
5. Arrange to use "%I64d" instead of "%lld" and "%I64u" instead of "%llu" for |
396 |
|
long printing in the pcrecpp unittest when running under MinGW. |
397 |
|
|
398 |
|
6. ESC_K was left out of the EBCDIC table. |
399 |
|
|
400 |
|
7. Change 7.0/38 introduced a new limit on the number of nested non-capturing |
401 |
|
parentheses; I made it 1000, which seemed large enough. Unfortunately, the |
402 |
|
limit also applies to "virtual nesting" when a pattern is recursive, and in |
403 |
|
this case 1000 isn't so big. I have been able to remove this limit at the |
404 |
|
expense of backing off one optimization in certain circumstances. Normally, |
405 |
|
when pcre_exec() would call its internal match() function recursively and |
406 |
|
immediately return the result unconditionally, it uses a "tail recursion" |
407 |
|
feature to save stack. However, when a subpattern that can match an empty |
408 |
|
string has an unlimited repetition quantifier, it no longer makes this |
409 |
|
optimization. That gives it a stack frame in which to save the data for |
410 |
|
checking that an empty string has been matched. Previously this was taken |
411 |
|
from the 1000-entry workspace that had been reserved. So now there is no |
412 |
|
explicit limit, but more stack is used. |
413 |
|
|
414 |
|
8. Applied Daniel's patches to solve problems with the import/export magic |
415 |
|
syntax that is required for Windows, and which was going wrong for the |
416 |
|
pcreposix and pcrecpp parts of the library. These were overlooked when this |
417 |
|
problem was solved for the main library. |
418 |
|
|
419 |
|
9. There were some crude static tests to avoid integer overflow when computing |
420 |
|
the size of patterns that contain repeated groups with explicit upper |
421 |
|
limits. As the maximum quantifier is 65535, the maximum group length was |
422 |
|
set at 30,000 so that the product of these two numbers did not overflow a |
423 |
|
32-bit integer. However, it turns out that people want to use groups that |
424 |
|
are longer than 30,000 bytes (though not repeat them that many times). |
425 |
|
Change 7.0/17 (the refactoring of the way the pattern size is computed) has |
426 |
|
made it possible to implement the integer overflow checks in a much more |
427 |
|
dynamic way, which I have now done. The artificial limitation on group |
428 |
|
length has been removed - we now have only the limit on the total length of |
429 |
|
the compiled pattern, which depends on the LINK_SIZE setting. |
430 |
|
|
431 |
|
10. Fixed a bug in the documentation for get/copy named substring when |
432 |
|
duplicate names are permitted. If none of the named substrings are set, the |
433 |
|
functions return PCRE_ERROR_NOSUBSTRING (7); the doc said they returned an |
434 |
|
empty string. |
435 |
|
|
436 |
|
11. Because Perl interprets \Q...\E at a high level, and ignores orphan \E |
437 |
|
instances, patterns such as [\Q\E] or [\E] or even [^\E] cause an error, |
438 |
|
because the ] is interpreted as the first data character and the |
439 |
|
terminating ] is not found. PCRE has been made compatible with Perl in this |
440 |
|
regard. Previously, it interpreted [\Q\E] as an empty class, and [\E] could |
441 |
|
cause memory overwriting. |
442 |
|
|
443 |
|
10. Like Perl, PCRE automatically breaks an unlimited repeat after an empty |
444 |
|
string has been matched (to stop an infinite loop). It was not recognizing |
445 |
|
a conditional subpattern that could match an empty string if that |
446 |
|
subpattern was within another subpattern. For example, it looped when |
447 |
|
trying to match (((?(1)X|))*) but it was OK with ((?(1)X|)*) where the |
448 |
|
condition was not nested. This bug has been fixed. |
449 |
|
|
450 |
|
12. A pattern like \X?\d or \P{L}?\d in non-UTF-8 mode could cause a backtrack |
451 |
|
past the start of the subject in the presence of bytes with the top bit |
452 |
|
set, for example "\x8aBCD". |
453 |
|
|
454 |
|
13. Added Perl 5.10 experimental backtracking controls (*FAIL), (*F), (*PRUNE), |
455 |
|
(*SKIP), (*THEN), (*COMMIT), and (*ACCEPT). |
456 |
|
|
457 |
|
14. Optimized (?!) to (*FAIL). |
458 |
|
|
459 |
|
15. Updated the test for a valid UTF-8 string to conform to the later RFC 3629. |
460 |
|
This restricts code points to be within the range 0 to 0x10FFFF, excluding |
461 |
|
the "low surrogate" sequence 0xD800 to 0xDFFF. Previously, PCRE allowed the |
462 |
|
full range 0 to 0x7FFFFFFF, as defined by RFC 2279. Internally, it still |
463 |
|
does: it's just the validity check that is more restrictive. |
464 |
|
|
465 |
|
16. Inserted checks for integer overflows during escape sequence (backslash) |
466 |
|
processing, and also fixed erroneous offset values for syntax errors during |
467 |
|
backslash processing. |
468 |
|
|
469 |
|
17. Fixed another case of looking too far back in non-UTF-8 mode (cf 12 above) |
470 |
|
for patterns like [\PPP\x8a]{1,}\x80 with the subject "A\x80". |
471 |
|
|
472 |
|
18. An unterminated class in a pattern like (?1)\c[ with a "forward reference" |
473 |
|
caused an overrun. |
474 |
|
|
475 |
|
19. A pattern like (?:[\PPa*]*){8,} which had an "extended class" (one with |
476 |
|
something other than just ASCII characters) inside a group that had an |
477 |
|
unlimited repeat caused a loop at compile time (while checking to see |
478 |
|
whether the group could match an empty string). |
479 |
|
|
480 |
|
20. Debugging a pattern containing \p or \P could cause a crash. For example, |
481 |
|
[\P{Any}] did so. (Error in the code for printing property names.) |
482 |
|
|
483 |
|
21. An orphan \E inside a character class could cause a crash. |
484 |
|
|
485 |
|
22. A repeated capturing bracket such as (A)? could cause a wild memory |
486 |
|
reference during compilation. |
487 |
|
|
488 |
|
23. There are several functions in pcre_compile() that scan along a compiled |
489 |
|
expression for various reasons (e.g. to see if it's fixed length for look |
490 |
|
behind). There were bugs in these functions when a repeated \p or \P was |
491 |
|
present in the pattern. These operators have additional parameters compared |
492 |
|
with \d, etc, and these were not being taken into account when moving along |
493 |
|
the compiled data. Specifically: |
494 |
|
|
495 |
|
(a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed |
496 |
|
length. |
497 |
|
|
498 |
|
(b) An item such as \pL+ within a repeated group could cause crashes or |
499 |
|
loops. |
500 |
|
|
501 |
|
(c) A pattern such as \p{Yi}+(\P{Yi}+)(?1) could give an incorrect |
502 |
|
"reference to non-existent subpattern" error. |
503 |
|
|
504 |
|
(d) A pattern like (\P{Yi}{2}\277)? could loop at compile time. |
505 |
|
|
506 |
|
24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte |
507 |
|
characters were involved (for example /\S{2}/8g with "A\x{a3}BC"). |
508 |
|
|
509 |
|
25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop. |
510 |
|
|
511 |
|
26. Patterns such as [\P{Yi}A] which include \p or \P and just one other |
512 |
|
character were causing crashes (broken optimization). |
513 |
|
|
514 |
|
27. Patterns such as (\P{Yi}*\277)* (group with possible zero repeat containing |
515 |
|
\p or \P) caused a compile-time loop. |
516 |
|
|
517 |
|
28. More problems have arisen in unanchored patterns when CRLF is a valid line |
518 |
|
break. For example, the unstudied pattern [\r\n]A does not match the string |
519 |
|
"\r\nA" because change 7.0/46 below moves the current point on by two |
520 |
|
characters after failing to match at the start. However, the pattern \nA |
521 |
|
*does* match, because it doesn't start till \n, and if [\r\n]A is studied, |
522 |
|
the same is true. There doesn't seem any very clean way out of this, but |
523 |
|
what I have chosen to do makes the common cases work: PCRE now takes note |
524 |
|
of whether there can be an explicit match for \r or \n anywhere in the |
525 |
|
pattern, and if so, 7.0/46 no longer applies. As part of this change, |
526 |
|
there's a new PCRE_INFO_HASCRORLF option for finding out whether a compiled |
527 |
|
pattern has explicit CR or LF references. |
528 |
|
|
529 |
|
29. Added (*CR) etc for changing newline setting at start of pattern. |
530 |
|
|
531 |
|
|
532 |
|
Version 7.2 19-Jun-07 |
533 |
|
--------------------- |
534 |
|
|
535 |
|
1. If the fr_FR locale cannot be found for test 3, try the "french" locale, |
536 |
|
which is apparently normally available under Windows. |
537 |
|
|
538 |
|
2. Re-jig the pcregrep tests with different newline settings in an attempt |
539 |
|
to make them independent of the local environment's newline setting. |
540 |
|
|
541 |
|
3. Add code to configure.ac to remove -g from the CFLAGS default settings. |
542 |
|
|
543 |
|
4. Some of the "internals" tests were previously cut out when the link size |
544 |
|
was not 2, because the output contained actual offsets. The recent new |
545 |
|
"Z" feature of pcretest means that these can be cut out, making the tests |
546 |
|
usable with all link sizes. |
547 |
|
|
548 |
|
5. Implemented Stan Switzer's goto replacement for longjmp() when not using |
549 |
|
stack recursion. This gives a massive performance boost under BSD, but just |
550 |
|
a small improvement under Linux. However, it saves one field in the frame |
551 |
|
in all cases. |
552 |
|
|
553 |
|
6. Added more features from the forthcoming Perl 5.10: |
554 |
|
|
555 |
|
(a) (?-n) (where n is a string of digits) is a relative subroutine or |
556 |
|
recursion call. It refers to the nth most recently opened parentheses. |
557 |
|
|
558 |
|
(b) (?+n) is also a relative subroutine call; it refers to the nth next |
559 |
|
to be opened parentheses. |
560 |
|
|
561 |
|
(c) Conditions that refer to capturing parentheses can be specified |
562 |
|
relatively, for example, (?(-2)... or (?(+3)... |
563 |
|
|
564 |
|
(d) \K resets the start of the current match so that everything before |
565 |
|
is not part of it. |
566 |
|
|
567 |
|
(e) \k{name} is synonymous with \k<name> and \k'name' (.NET compatible). |
568 |
|
|
569 |
|
(f) \g{name} is another synonym - part of Perl 5.10's unification of |
570 |
|
reference syntax. |
571 |
|
|
572 |
|
(g) (?| introduces a group in which the numbering of parentheses in each |
573 |
|
alternative starts with the same number. |
574 |
|
|
575 |
|
(h) \h, \H, \v, and \V match horizontal and vertical whitespace. |
576 |
|
|
577 |
|
7. Added two new calls to pcre_fullinfo(): PCRE_INFO_OKPARTIAL and |
578 |
|
PCRE_INFO_JCHANGED. |
579 |
|
|
580 |
|
8. A pattern such as (.*(.)?)* caused pcre_exec() to fail by either not |
581 |
|
terminating or by crashing. Diagnosed by Viktor Griph; it was in the code |
582 |
|
for detecting groups that can match an empty string. |
583 |
|
|
584 |
|
9. A pattern with a very large number of alternatives (more than several |
585 |
|
hundred) was running out of internal workspace during the pre-compile |
586 |
|
phase, where pcre_compile() figures out how much memory will be needed. A |
587 |
|
bit of new cunning has reduced the workspace needed for groups with |
588 |
|
alternatives. The 1000-alternative test pattern now uses 12 bytes of |
589 |
|
workspace instead of running out of the 4096 that are available. |
590 |
|
|
591 |
|
10. Inserted some missing (unsigned int) casts to get rid of compiler warnings. |
592 |
|
|
593 |
|
11. Applied patch from Google to remove an optimization that didn't quite work. |
594 |
|
The report of the bug said: |
595 |
|
|
596 |
|
pcrecpp::RE("a*").FullMatch("aaa") matches, while |
597 |
|
pcrecpp::RE("a*?").FullMatch("aaa") does not, and |
598 |
|
pcrecpp::RE("a*?\\z").FullMatch("aaa") does again. |
599 |
|
|
600 |
|
12. If \p or \P was used in non-UTF-8 mode on a character greater than 127 |
601 |
|
it matched the wrong number of bytes. |
602 |
|
|
603 |
|
|
604 |
|
Version 7.1 24-Apr-07 |
605 |
|
--------------------- |
606 |
|
|
607 |
|
1. Applied Bob Rossi and Daniel G's patches to convert the build system to one |
608 |
|
that is more "standard", making use of automake and other Autotools. There |
609 |
is some re-arrangement of the files and adjustment of comments consequent |
is some re-arrangement of the files and adjustment of comments consequent |
610 |
on this. |
on this. |
611 |
|
|
612 |
2. Part of the patch fixed a problem with the pcregrep tests. The test of -r |
2. Part of the patch fixed a problem with the pcregrep tests. The test of -r |
613 |
for recursive directory scanning broke on some systems because the files |
for recursive directory scanning broke on some systems because the files |
614 |
are not scanned in any specific order and on different systems the order |
are not scanned in any specific order and on different systems the order |
615 |
was different. A call to "sort" has been inserted into RunGrepTest for the |
was different. A call to "sort" has been inserted into RunGrepTest for the |
616 |
approprate test as a short-term fix. In the longer term there may be an |
approprate test as a short-term fix. In the longer term there may be an |
617 |
alternative. |
alternative. |
618 |
|
|
619 |
3. I had an email from Eric Raymond about problems translating some of PCRE's |
3. I had an email from Eric Raymond about problems translating some of PCRE's |
620 |
man pages to HTML (despite the fact that I distribute HTML pages, some |
man pages to HTML (despite the fact that I distribute HTML pages, some |
621 |
people do their own conversions for various reasons). The problems |
people do their own conversions for various reasons). The problems |
622 |
concerned the use of low-level troff macros .br and .in. I have therefore |
concerned the use of low-level troff macros .br and .in. I have therefore |
623 |
removed all such uses from the man pages (some were redundant, some could |
removed all such uses from the man pages (some were redundant, some could |
624 |
be replaced by .nf/.fi pairs). The maintain/132html script that I use to |
be replaced by .nf/.fi pairs). The 132html script that I use to generate |
625 |
generate HTML has been updated to handle .nf/.fi and to complain if it |
HTML has been updated to handle .nf/.fi and to complain if it encounters |
626 |
encounters .br or .in. |
.br or .in. |
627 |
|
|
628 |
4. Updated comments in configure.ac that get placed in config.h.in and also |
4. Updated comments in configure.ac that get placed in config.h.in and also |
629 |
arranged for config.h to be included in the distribution, for the benefit |
arranged for config.h to be included in the distribution, with the name |
630 |
of those who have to compile without Autotools (compare pcre.h). |
config.h.generic, for the benefit of those who have to compile without |
631 |
|
Autotools (compare pcre.h, which is now distributed as pcre.h.generic). |
632 |
5. Updated the support (such as it is) for Virtual Pascal, thanks to Stefan |
|
633 |
Weber: (1) pcre_internal.h was missing some function renames; (2) updated |
5. Updated the support (such as it is) for Virtual Pascal, thanks to Stefan |
634 |
makevp.bat for the current PCRE, using the additional files !compile.txt, |
Weber: (1) pcre_internal.h was missing some function renames; (2) updated |
635 |
!linklib.txt, and pcregexp.pas. |
makevp.bat for the current PCRE, using the additional files |
636 |
|
makevp_c.txt, makevp_l.txt, and pcregexp.pas. |
637 |
6. A Windows user reported a minor discrepancy with test 2, which turned out |
|
638 |
to be caused by a trailing space on an input line that had got lost in his |
6. A Windows user reported a minor discrepancy with test 2, which turned out |
639 |
|
to be caused by a trailing space on an input line that had got lost in his |
640 |
copy. The trailing space was an accident, so I've just removed it. |
copy. The trailing space was an accident, so I've just removed it. |
641 |
|
|
642 |
7. Add -Wl,-R... flags in pcre-config.in for *BSD* systems, as I'm told |
7. Add -Wl,-R... flags in pcre-config.in for *BSD* systems, as I'm told |
643 |
that is needed. |
that is needed. |
644 |
|
|
645 |
8. Mark ucp_table (in ucptable.h) and ucp_gentype (in pcre_ucp_searchfuncs.c) |
8. Mark ucp_table (in ucptable.h) and ucp_gentype (in pcre_ucp_searchfuncs.c) |
646 |
as "const" (a) because they are and (b) because it helps the PHP |
as "const" (a) because they are and (b) because it helps the PHP |
647 |
maintainers who have recently made a script to detect big data structures |
maintainers who have recently made a script to detect big data structures |
648 |
in the php code that should be moved to the .rodata section. I remembered |
in the php code that should be moved to the .rodata section. I remembered |
649 |
to update Builducptable as well, so it won't revert if ucptable.h is ever |
to update Builducptable as well, so it won't revert if ucptable.h is ever |
650 |
re-created. |
re-created. |
651 |
|
|
652 |
9. Added some extra #ifdef SUPPORT_UTF8 conditionals into pcretest.c, |
9. Added some extra #ifdef SUPPORT_UTF8 conditionals into pcretest.c, |
653 |
pcre_printint.src, pcre_compile.c, pcre_study.c, and pcre_tables.c, in |
pcre_printint.src, pcre_compile.c, pcre_study.c, and pcre_tables.c, in |
654 |
order to be able to cut out the UTF-8 tables in the latter when UTF-8 |
order to be able to cut out the UTF-8 tables in the latter when UTF-8 |
655 |
support is not required. This saves 1.5-2K of code, which is important in |
support is not required. This saves 1.5-2K of code, which is important in |
656 |
some applications. |
some applications. |
657 |
|
|
658 |
10. The emulated memmove() function in pcre_internal.h (provided for those |
Later: more #ifdefs are needed in pcre_ord2utf8.c and pcre_valid_utf8.c |
659 |
environments that have neither memmove() nor bcopy()) was defining its |
so as not to refer to the tables, even though these functions will never be |
660 |
arguments as char * instead of void *. |
called when UTF-8 support is disabled. Otherwise there are problems with a |
661 |
|
shared library. |
662 |
|
|
663 |
|
10. Fixed two bugs in the emulated memmove() function in pcre_internal.h: |
664 |
|
|
665 |
|
(a) It was defining its arguments as char * instead of void *. |
666 |
|
|
667 |
|
(b) It was assuming that all moves were upwards in memory; this was true |
668 |
|
a long time ago when I wrote it, but is no longer the case. |
669 |
|
|
670 |
|
The emulated memove() is provided for those environments that have neither |
671 |
|
memmove() nor bcopy(). I didn't think anyone used it these days, but that |
672 |
|
is clearly not the case, as these two bugs were recently reported. |
673 |
|
|
674 |
|
11. The script PrepareRelease is now distributed: it calls 132html, CleanTxt, |
675 |
|
and Detrail to create the HTML documentation, the .txt form of the man |
676 |
|
pages, and it removes trailing spaces from listed files. It also creates |
677 |
|
pcre.h.generic and config.h.generic from pcre.h and config.h. In the latter |
678 |
|
case, it wraps all the #defines with #ifndefs. This script should be run |
679 |
|
before "make dist". |
680 |
|
|
681 |
|
12. Fixed two fairly obscure bugs concerned with quantified caseless matching |
682 |
|
with Unicode property support. |
683 |
|
|
684 |
|
(a) For a maximizing quantifier, if the two different cases of the |
685 |
|
character were of different lengths in their UTF-8 codings (there are |
686 |
|
some cases like this - I found 11), and the matching function had to |
687 |
|
back up over a mixture of the two cases, it incorrectly assumed they |
688 |
|
were both the same length. |
689 |
|
|
690 |
|
(b) When PCRE was configured to use the heap rather than the stack for |
691 |
|
recursion during matching, it was not correctly preserving the data for |
692 |
|
the other case of a UTF-8 character when checking ahead for a match |
693 |
|
while processing a minimizing repeat. If the check also involved |
694 |
|
matching a wide character, but failed, corruption could cause an |
695 |
|
erroneous result when trying to check for a repeat of the original |
696 |
|
character. |
697 |
|
|
698 |
|
13. Some tidying changes to the testing mechanism: |
699 |
|
|
700 |
|
(a) The RunTest script now detects the internal link size and whether there |
701 |
|
is UTF-8 and UCP support by running ./pcretest -C instead of relying on |
702 |
|
values substituted by "configure". (The RunGrepTest script already did |
703 |
|
this for UTF-8.) The configure.ac script no longer substitutes the |
704 |
|
relevant variables. |
705 |
|
|
706 |
|
(b) The debugging options /B and /D in pcretest show the compiled bytecode |
707 |
|
with length and offset values. This means that the output is different |
708 |
|
for different internal link sizes. Test 2 is skipped for link sizes |
709 |
|
other than 2 because of this, bypassing the problem. Unfortunately, |
710 |
|
there was also a test in test 3 (the locale tests) that used /B and |
711 |
|
failed for link sizes other than 2. Rather than cut the whole test out, |
712 |
|
I have added a new /Z option to pcretest that replaces the length and |
713 |
|
offset values with spaces. This is now used to make test 3 independent |
714 |
|
of link size. (Test 2 will be tidied up later.) |
715 |
|
|
716 |
|
14. If erroroffset was passed as NULL to pcre_compile, it provoked a |
717 |
|
segmentation fault instead of returning the appropriate error message. |
718 |
|
|
719 |
|
15. In multiline mode when the newline sequence was set to "any", the pattern |
720 |
|
^$ would give a match between the \r and \n of a subject such as "A\r\nB". |
721 |
|
This doesn't seem right; it now treats the CRLF combination as the line |
722 |
|
ending, and so does not match in that case. It's only a pattern such as ^$ |
723 |
|
that would hit this one: something like ^ABC$ would have failed after \r |
724 |
|
and then tried again after \r\n. |
725 |
|
|
726 |
|
16. Changed the comparison command for RunGrepTest from "diff -u" to "diff -ub" |
727 |
|
in an attempt to make files that differ only in their line terminators |
728 |
|
compare equal. This works on Linux. |
729 |
|
|
730 |
|
17. Under certain error circumstances pcregrep might try to free random memory |
731 |
|
as it exited. This is now fixed, thanks to valgrind. |
732 |
|
|
733 |
|
19. In pcretest, if the pattern /(?m)^$/g<any> was matched against the string |
734 |
|
"abc\r\n\r\n", it found an unwanted second match after the second \r. This |
735 |
|
was because its rules for how to advance for /g after matching an empty |
736 |
|
string at the end of a line did not allow for this case. They now check for |
737 |
|
it specially. |
738 |
|
|
739 |
|
20. pcretest is supposed to handle patterns and data of any length, by |
740 |
|
extending its buffers when necessary. It was getting this wrong when the |
741 |
|
buffer for a data line had to be extended. |
742 |
|
|
743 |
|
21. Added PCRE_NEWLINE_ANYCRLF which is like ANY, but matches only CR, LF, or |
744 |
|
CRLF as a newline sequence. |
745 |
|
|
746 |
|
22. Code for handling Unicode properties in pcre_dfa_exec() wasn't being cut |
747 |
|
out by #ifdef SUPPORT_UCP. This did no harm, as it could never be used, but |
748 |
|
I have nevertheless tidied it up. |
749 |
|
|
750 |
|
23. Added some casts to kill warnings from HP-UX ia64 compiler. |
751 |
|
|
752 |
|
24. Added a man page for pcre-config. |
753 |
|
|
754 |
|
|
755 |
Version 7.0 19-Dec-06 |
Version 7.0 19-Dec-06 |
756 |
--------------------- |
--------------------- |