| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 7.2 19-June-07 |
Version 7.3 05-Jul-07 |
| 5 |
|
--------------------- |
| 6 |
|
|
| 7 |
|
1. In the rejigging of the build system that eventually resulted in 7.1, the |
| 8 |
|
line "#include <pcre.h>" was included in pcre_internal.h. The use of angle |
| 9 |
|
brackets there is not right, since it causes compilers to look for an |
| 10 |
|
installed pcre.h, not the version that is in the source that is being |
| 11 |
|
compiled (which of course may be different). I have changed it back to: |
| 12 |
|
|
| 13 |
|
#include "pcre.h" |
| 14 |
|
|
| 15 |
|
I have a vague recollection that the change was concerned with compiling in |
| 16 |
|
different directories, but in the new build system, that is taken care of |
| 17 |
|
by the VPATH setting the Makefile. |
| 18 |
|
|
| 19 |
|
2. The pattern .*$ when run in not-DOTALL UTF-8 mode with newline=any failed |
| 20 |
|
when the subject happened to end in the byte 0x85 (e.g. if the last |
| 21 |
|
character was \x{1ec5}). *Character* 0x85 is one of the "any" newline |
| 22 |
|
characters but of course it shouldn't be taken as a newline when it is part |
| 23 |
|
of another character. The bug was that, for an unlimited repeat of . in |
| 24 |
|
not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by |
| 25 |
|
characters when looking for a newline. |
| 26 |
|
|
| 27 |
|
3. A small performance improvement in the DOTALL UTF-8 mode .* case. |
| 28 |
|
|
| 29 |
|
4. Debugging: adjusted the names of opcodes for different kinds of parentheses |
| 30 |
|
in debug output. |
| 31 |
|
|
| 32 |
|
5. Arrange to use "%I64d" instead of "%lld" for long printing in the pcrecpp |
| 33 |
|
unittest when running under MinGW. |
| 34 |
|
|
| 35 |
|
6. ESC_K was left out of the EBCDIC table. |
| 36 |
|
|
| 37 |
|
7. Change 7.0/38 introduced a new limit on the number of nested non-capturing |
| 38 |
|
parentheses; I made it 1000, which seemed large enough. Unfortunately, the |
| 39 |
|
limit also applies to "virtual nesting" when a pattern is recursive, and in |
| 40 |
|
this case 1000 isn't so big. I have been able to remove this limit at the |
| 41 |
|
expense of backing off one optimization in certain circumstances. Normally, |
| 42 |
|
when pcre_exec() would call its internal match() function recursively and |
| 43 |
|
immediately return the result unconditionally, it uses a "tail recursion" |
| 44 |
|
feature to save stack. However, when a subpattern that can match an empty |
| 45 |
|
string has an unlimited repetition quantifier, it no longer makes this |
| 46 |
|
optimization. That gives it a stack frame in which to save the data for |
| 47 |
|
checking that an empty string has been matched. Previously this was taken |
| 48 |
|
from the 1000-entry workspace that had been reserved. So now there is no |
| 49 |
|
explicit limit, but more stack is used. |
| 50 |
|
|
| 51 |
|
|
| 52 |
|
Version 7.2 19-Jun-07 |
| 53 |
--------------------- |
--------------------- |
| 54 |
|
|
| 55 |
1. If the fr_FR locale cannot be found for test 3, try the "french" locale, |
1. If the fr_FR locale cannot be found for test 3, try the "french" locale, |
Parent Directory
| 
Revision Log
| 
Patch