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