| 9 |
brackets there is not right, since it causes compilers to look for an |
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 |
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: |
compiled (which of course may be different). I have changed it back to: |
| 12 |
|
|
| 13 |
#include "pcre.h" |
#include "pcre.h" |
| 14 |
|
|
| 15 |
I have a vague recollection that the change was concerned with compiling in |
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 |
different directories, but in the new build system, that is taken care of |
| 17 |
by the VPATH setting the Makefile. |
by the VPATH setting the Makefile. |
| 18 |
|
|
| 19 |
2. The pattern .*$ when run in not-DOTALL UTF-8 mode with newline=any failed |
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 |
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 |
character was \x{1ec5}). *Character* 0x85 is one of the "any" newline |
| 23 |
of another character. The bug was that, for an unlimited repeat of . in |
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 |
not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by |
| 25 |
characters when looking for a newline. |
characters when looking for a newline. |
| 26 |
|
|
| 27 |
3. A small performance improvement in the DOTALL UTF-8 mode .* case. |
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 |
4. Debugging: adjusted the names of opcodes for different kinds of parentheses |
| 30 |
in debug output. |
in debug output. |
| 31 |
|
|
| 32 |
5. Arrange to use "%I64d" instead of "%lld" for long printing in the pcrecpp |
5. Arrange to use "%I64d" instead of "%lld" for long printing in the pcrecpp |
| 33 |
unittest when running under MinGW. |
unittest when running under MinGW. |
| 34 |
|
|
| 35 |
6. ESC_K was left out of the EBCDIC table. |
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 |
Version 7.2 19-Jun-07 |
Parent Directory
| 
Revision Log
| 
Patch