| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 8.01 06-Jan-10 |
Version 8.02 01-Mar-2010 |
| 5 |
---------------------- |
------------------------ |
| 6 |
|
|
| 7 |
|
1. The Unicode data tables have been updated to Unicode 5.2.0. |
| 8 |
|
|
| 9 |
|
2. Added the option --libs-cpp to pcre-config, but only when C++ support is |
| 10 |
|
configured. |
| 11 |
|
|
| 12 |
|
3. Updated the licensing terms in the pcregexp.pas file, as agreed with the |
| 13 |
|
original author of that file, following a query about its status. |
| 14 |
|
|
| 15 |
|
4. On systems that do not have stdint.h (e.g. Solaris), check for and include |
| 16 |
|
inttypes.h instead. This fixes a bug that was introduced by change 8.01/8. |
| 17 |
|
|
| 18 |
|
5. A pattern such as (?&t)*+(?(DEFINE)(?<t>.)) which has a possessive |
| 19 |
|
quantifier applied to a forward-referencing subroutine call, could compile |
| 20 |
|
incorrect code or give the error "internal error: previously-checked |
| 21 |
|
referenced subpattern not found". |
| 22 |
|
|
| 23 |
|
6. Both MS Visual Studio and Symbian OS have problems with initializing |
| 24 |
|
variables to point to external functions. For these systems, therefore, |
| 25 |
|
pcre_malloc etc. are now initialized to local functions that call the |
| 26 |
|
relevant global functions. |
| 27 |
|
|
| 28 |
|
7. There were two entries missing in the vectors called coptable and poptable |
| 29 |
|
in pcre_dfa_exec.c. This could lead to memory accesses outsize the vectors. |
| 30 |
|
I've fixed the data, and added a kludgy way of testing at compile time that |
| 31 |
|
the lengths are correct (equal to the number of opcodes). |
| 32 |
|
|
| 33 |
|
8. Following on from 7, I added a similar kludge to check the length of the |
| 34 |
|
eint vector in pcreposix.c. |
| 35 |
|
|
| 36 |
|
9. Error texts for pcre_compile() are held as one long string to avoid too |
| 37 |
|
much relocation at load time. To find a text, the string is searched, |
| 38 |
|
counting zeros. There was no check for running off the end of the string, |
| 39 |
|
which could happen if a new error number was added without updating the |
| 40 |
|
string. |
| 41 |
|
|
| 42 |
|
10. \K gave a compile-time error if it appeared in a lookbehind assersion. |
| 43 |
|
|
| 44 |
|
11. \K was not working if it appeared in an atomic group or in a group that |
| 45 |
|
was called as a "subroutine", or in an assertion. Perl 5.11 documents that |
| 46 |
|
\K is "not well defined" if used in an assertion. PCRE now accepts it if |
| 47 |
|
the assertion is positive, but not if it is negative. |
| 48 |
|
|
| 49 |
|
12. Change 11 fortuitously reduced the size of the stack frame used in the |
| 50 |
|
"match()" function of pcre_exec.c by one pointer. Forthcoming |
| 51 |
|
implementation of support for (*MARK) will need an extra pointer on the |
| 52 |
|
stack; I have reserved it now, so that the stack frame size does not |
| 53 |
|
decrease. |
| 54 |
|
|
| 55 |
|
13. A pattern such as (?P<L1>(?P<L2>0)|(?P>L2)(?P>L1)) in which the only other |
| 56 |
|
item in branch that calls a recursion is a subroutine call - as in the |
| 57 |
|
second branch in the above example - was incorrectly given the compile- |
| 58 |
|
time error "recursive call could loop indefinitely" because pcre_compile() |
| 59 |
|
was not correctly checking the subroutine for matching a non-empty string. |
| 60 |
|
|
| 61 |
|
14. The checks for overrunning compiling workspace could trigger after an |
| 62 |
|
overrun had occurred. This is a "should never occur" error, but it can be |
| 63 |
|
triggered by pathological patterns such as hundreds of nested parentheses. |
| 64 |
|
The checks now trigger 100 bytes before the end of the workspace. |
| 65 |
|
|
| 66 |
|
15. Fix typo in configure.ac: "srtoq" should be "strtoq". |
| 67 |
|
|
| 68 |
|
|
| 69 |
|
Version 8.01 19-Jan-2010 |
| 70 |
|
------------------------ |
| 71 |
|
|
| 72 |
1. If a pattern contained a conditional subpattern with only one branch (in |
1. If a pattern contained a conditional subpattern with only one branch (in |
| 73 |
particular, this includes all (DEFINE) patterns), a call to pcre_study() |
particular, this includes all (*DEFINE) patterns), a call to pcre_study() |
| 74 |
computed the wrong minimum data length (which is of course zero for such |
computed the wrong minimum data length (which is of course zero for such |
| 75 |
subpatterns). |
subpatterns). This could cause incorrect "no match" results. |
| 76 |
|
|
| 77 |
2. For patterns such as (?i)a(?-i)b|c where an option setting at the start of |
2. For patterns such as (?i)a(?-i)b|c where an option setting at the start of |
| 78 |
the pattern is reset in the first branch, pcre_compile() failed with |
the pattern is reset in the first branch, pcre_compile() failed with |
| 126 |
custom one, because of the following reported problem in Windows: |
custom one, because of the following reported problem in Windows: |
| 127 |
|
|
| 128 |
- libbz2 uses the Pascal calling convention (WINAPI) for the functions |
- libbz2 uses the Pascal calling convention (WINAPI) for the functions |
| 129 |
under Win32. |
under Win32. |
| 130 |
- The standard autoconf AC_CHECK_LIB fails to include "bzlib.h", |
- The standard autoconf AC_CHECK_LIB fails to include "bzlib.h", |
| 131 |
therefore missing the function definition. |
therefore missing the function definition. |
| 132 |
- The compiler thus generates a "C" signature for the test function. |
- The compiler thus generates a "C" signature for the test function. |
| 133 |
- The linker fails to find the "C" function. |
- The linker fails to find the "C" function. |
| 134 |
- PCRE fails to configure if asked to do so against libbz2. |
- PCRE fails to configure if asked to do so against libbz2. |
| 178 |
equivalent. It's not enough to call AC_CHECK_FUNCS: hpux has a strtoll, for |
equivalent. It's not enough to call AC_CHECK_FUNCS: hpux has a strtoll, for |
| 179 |
instance, but it only takes 2 args instead of 3!" |
instance, but it only takes 2 args instead of 3!" |
| 180 |
|
|
| 181 |
|
18. A subtle bug concerned with back references has been fixed by a change of |
| 182 |
|
specification, with a corresponding code fix. A pattern such as |
| 183 |
|
^(xa|=?\1a)+$ which contains a back reference inside the group to which it |
| 184 |
|
refers, was giving matches when it shouldn't. For example, xa=xaaa would |
| 185 |
|
match that pattern. Interestingly, Perl (at least up to 5.11.3) has the |
| 186 |
|
same bug. Such groups have to be quantified to be useful, or contained |
| 187 |
|
inside another quantified group. (If there's no repetition, the reference |
| 188 |
|
can never match.) The problem arises because, having left the group and |
| 189 |
|
moved on to the rest of the pattern, a later failure that backtracks into |
| 190 |
|
the group uses the captured value from the final iteration of the group |
| 191 |
|
rather than the correct earlier one. I have fixed this in PCRE by forcing |
| 192 |
|
any group that contains a reference to itself to be an atomic group; that |
| 193 |
|
is, there cannot be any backtracking into it once it has completed. This is |
| 194 |
|
similar to recursive and subroutine calls. |
| 195 |
|
|
| 196 |
|
|
| 197 |
Version 8.00 19-Oct-09 |
Version 8.00 19-Oct-09 |
| 198 |
---------------------- |
---------------------- |
Parent Directory
| 
Revision Log
| 
Patch