| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 8.00 ??-???-?? |
Version 8.01 11-Dec-09 |
| 5 |
---------------------- |
---------------------- |
| 6 |
|
|
| 7 |
1. The table for translating pcre_compile() error codes into POSIX error codes |
1. If a pattern contained a conditional subpattern with only one branch (in |
| 8 |
was out-of-date, and there was no check on the pcre_compile() error code |
particular, this includes all (DEFINE) patterns), a call to pcre_study() |
| 9 |
being within the table. This could lead to an OK return being given in |
computed the wrong minimum data length (which is of course zero for such |
| 10 |
error. |
subpatterns). |
| 11 |
|
|
| 12 |
|
2. For patterns such as (?i)a(?-i)b|c where an option setting at the start of |
| 13 |
|
the pattern is reset in the first branch, pcre_compile() failed with |
| 14 |
|
"internal error: code overflow at offset...". This happened only when |
| 15 |
|
the reset was to the original external option setting. (An optimization |
| 16 |
|
abstracts leading options settings into an external setting, which was the |
| 17 |
|
cause of this.) |
| 18 |
|
|
| 19 |
|
3. A pattern such as ^(?!a(*SKIP)b) where a negative assertion contained one |
| 20 |
|
of the verbs SKIP, PRUNE, or COMMIT, did not work correctly. When the |
| 21 |
|
assertion pattern did not match (meaning that the assertion was true), it |
| 22 |
|
was incorrectly treated as false if the SKIP had been reached during the |
| 23 |
|
matching. This also applied to assertions used as conditions. |
| 24 |
|
|
| 25 |
|
4. If an item that is not supported by pcre_dfa_exec() was encountered in an |
| 26 |
|
assertion subpattern, including such a pattern used as a condition, |
| 27 |
|
unpredictable results occurred, instead of the error return |
| 28 |
|
PCRE_ERROR_DFA_UITEM. |
| 29 |
|
|
| 30 |
|
5. The C++ GlobalReplace function was not working like Perl for the special |
| 31 |
|
situation when an empty string is matched. It now does the fancy magic |
| 32 |
|
stuff that is necessary. |
| 33 |
|
|
| 34 |
|
6. In pcre_internal.h, obsolete includes to setjmp.h and stdarg.h have been |
| 35 |
|
removed. (These were left over from very, very early versions of PCRE.) |
| 36 |
|
|
| 37 |
|
7. Some cosmetic changes to the code to make life easier when compiling it |
| 38 |
|
as part of something else: |
| 39 |
|
|
| 40 |
|
(a) Change DEBUG to PCRE_DEBUG. |
| 41 |
|
|
| 42 |
|
(b) In pcre_compile(), rename the member of the "branch_chain" structure |
| 43 |
|
called "current" as "current_branch", to prevent a collision with the |
| 44 |
|
Linux macro when compiled as a kernel module. |
| 45 |
|
|
| 46 |
|
(c) In pcre_study(), rename the function set_bit() as set_table_bit(), to |
| 47 |
|
prevent a collision with the Linux macro when compiled as a kernel |
| 48 |
|
module. |
| 49 |
|
|
| 50 |
|
8. In pcre_compile() there are some checks for integer overflows that used to |
| 51 |
|
cast potentially large values to (double). This has been changed to that |
| 52 |
|
when building, a check for int64_t is made, and if it is found, it is used |
| 53 |
|
instead, thus avoiding the use of floating point arithmetic. (There is no |
| 54 |
|
other use of FP in PCRE.) If int64_t is not found, the fallback is to |
| 55 |
|
double. |
| 56 |
|
|
| 57 |
|
9. Added two casts to avoid signed/unsigned warnings from VS Studio Express |
| 58 |
|
2005 (difference between two addresses compared to an unsigned value). |
| 59 |
|
|
| 60 |
|
10. Change the standard AC_CHECK_LIB test for libbz2 in configure.ac to a |
| 61 |
|
custom one, because of the following reported problem in Windows: |
| 62 |
|
|
| 63 |
|
- libbz2 uses the Pascal calling convention (WINAPI) for the functions |
| 64 |
|
under Win32. |
| 65 |
|
- The standard autoconf AC_CHECK_LIB fails to include "bzlib.h", |
| 66 |
|
therefore missing the function definition. |
| 67 |
|
- The compiler thus generates a "C" signature for the test function. |
| 68 |
|
- The linker fails to find the "C" function. |
| 69 |
|
- PCRE fails to configure if asked to do so against libbz2. |
| 70 |
|
|
| 71 |
|
11. When running libtoolize from libtool-2.2.6b as part of autogen.sh, these |
| 72 |
|
messages were output: |
| 73 |
|
|
| 74 |
|
Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and |
| 75 |
|
rerunning libtoolize, to keep the correct libtool macros in-tree. |
| 76 |
|
Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. |
| 77 |
|
|
| 78 |
|
I have done both of these things. |
| 79 |
|
|
| 80 |
|
12. Although pcre_dfa_exec() does not use nearly as much stack as pcre_exec() |
| 81 |
|
most of the time, it *can* run out if it is given a pattern that contains a |
| 82 |
|
runaway infinite recursion. I updated the discussion in the pcrestack man |
| 83 |
|
page. |
| 84 |
|
|
| 85 |
|
13. Now that we have gone to the x.xx style of version numbers, the minor |
| 86 |
|
version may start with zero. Using 08 or 09 is a bad idea because users |
| 87 |
|
might check the value of PCRE_MINOR in their code, and 08 or 09 may be |
| 88 |
|
interpreted as invalid octal numbers. I've updated the previous comment in |
| 89 |
|
configure.ac, and also added a check that gives an error if 08 or 09 are |
| 90 |
|
used. |
| 91 |
|
|
| 92 |
2. Changed the call to open a subject file in pcregrep from fopen(pathname, |
14. Change 8.00/11 was not quite complete: code had been accidentally omitted, |
| 93 |
"r") to fopen(pathname, "rb"), which fixed a problem with some of the tests |
causing partial matching to fail when the end of the subject matched \W |
| 94 |
in a Windows environment. |
in a UTF-8 pattern where \W was quantified with a minimum of 3. |
| 95 |
|
|
| 96 |
|
15. There were some discrepancies between the declarations in pcre_internal.h |
| 97 |
|
of _pcre_is_newline(), _pcre_was_newline(), and _pcre_valid_utf8() and |
| 98 |
|
their definitions. The declarations used "const uschar *" and the |
| 99 |
|
definitions used USPTR. Even though USPTR is normally defined as "const |
| 100 |
|
unsigned char *" (and uschar is typedeffed as "unsigned char"), it was |
| 101 |
|
reported that: "This difference in casting confuses some C++ compilers, for |
| 102 |
|
example, SunCC recognizes above declarations as different functions and |
| 103 |
|
generates broken code for hbpcre." I have changed the declarations to use |
| 104 |
|
USPTR. |
| 105 |
|
|
| 106 |
|
16. GNU libtool is named differently on some systems. The autogen.sh script now |
| 107 |
|
tries several variants such as glibtoolize (MacOSX) and libtoolize1x |
| 108 |
|
(FreeBSD). |
| 109 |
|
|
| 110 |
|
|
| 111 |
|
|
| 112 |
|
Version 8.00 19-Oct-09 |
| 113 |
|
---------------------- |
| 114 |
|
|
| 115 |
|
1. The table for translating pcre_compile() error codes into POSIX error codes |
| 116 |
|
was out-of-date, and there was no check on the pcre_compile() error code |
| 117 |
|
being within the table. This could lead to an OK return being given in |
| 118 |
|
error. |
| 119 |
|
|
| 120 |
|
2. Changed the call to open a subject file in pcregrep from fopen(pathname, |
| 121 |
|
"r") to fopen(pathname, "rb"), which fixed a problem with some of the tests |
| 122 |
|
in a Windows environment. |
| 123 |
|
|
| 124 |
3. The pcregrep --count option prints the count for each file even when it is |
3. The pcregrep --count option prints the count for each file even when it is |
| 125 |
zero, as does GNU grep. However, pcregrep was also printing all files when |
zero, as does GNU grep. However, pcregrep was also printing all files when |
| 126 |
--files-with-matches was added. Now, when both options are given, it prints |
--files-with-matches was added. Now, when both options are given, it prints |
| 127 |
counts only for those files that have at least one match. (GNU grep just |
counts only for those files that have at least one match. (GNU grep just |
| 128 |
prints the file name in this circumstance, but including the count seems |
prints the file name in this circumstance, but including the count seems |
| 129 |
more useful - otherwise, why use --count?) Also ensured that the |
more useful - otherwise, why use --count?) Also ensured that the |
| 130 |
combination -clh just lists non-zero counts, with no names. |
combination -clh just lists non-zero counts, with no names. |
| 131 |
|
|
| 132 |
4. The long form of the pcregrep -F option was incorrectly implemented as |
4. The long form of the pcregrep -F option was incorrectly implemented as |
| 133 |
--fixed_strings instead of --fixed-strings. This is an incompatible change, |
--fixed_strings instead of --fixed-strings. This is an incompatible change, |
| 134 |
but it seems right to fix it, and I didn't think it was worth preserving |
but it seems right to fix it, and I didn't think it was worth preserving |
| 135 |
the old behaviour. |
the old behaviour. |
| 136 |
|
|
| 137 |
|
5. The command line items --regex=pattern and --regexp=pattern were not |
| 138 |
|
recognized by pcregrep, which required --regex pattern or --regexp pattern |
| 139 |
|
(with a space rather than an '='). The man page documented the '=' forms, |
| 140 |
|
which are compatible with GNU grep; these now work. |
| 141 |
|
|
| 142 |
|
6. No libpcreposix.pc file was created for pkg-config; there was just |
| 143 |
|
libpcre.pc and libpcrecpp.pc. The omission has been rectified. |
| 144 |
|
|
| 145 |
|
7. Added #ifndef SUPPORT_UCP into the pcre_ucd.c module, to reduce its size |
| 146 |
|
when UCP support is not needed, by modifying the Python script that |
| 147 |
|
generates it from Unicode data files. This should not matter if the module |
| 148 |
|
is correctly used as a library, but I received one complaint about 50K of |
| 149 |
|
unwanted data. My guess is that the person linked everything into his |
| 150 |
|
program rather than using a library. Anyway, it does no harm. |
| 151 |
|
|
| 152 |
|
8. A pattern such as /\x{123}{2,2}+/8 was incorrectly compiled; the trigger |
| 153 |
|
was a minimum greater than 1 for a wide character in a possessive |
| 154 |
|
repetition. The same bug could also affect patterns like /(\x{ff}{0,2})*/8 |
| 155 |
|
which had an unlimited repeat of a nested, fixed maximum repeat of a wide |
| 156 |
|
character. Chaos in the form of incorrect output or a compiling loop could |
| 157 |
|
result. |
| 158 |
|
|
| 159 |
|
9. The restrictions on what a pattern can contain when partial matching is |
| 160 |
|
requested for pcre_exec() have been removed. All patterns can now be |
| 161 |
|
partially matched by this function. In addition, if there are at least two |
| 162 |
|
slots in the offset vector, the offset of the earliest inspected character |
| 163 |
|
for the match and the offset of the end of the subject are set in them when |
| 164 |
|
PCRE_ERROR_PARTIAL is returned. |
| 165 |
|
|
| 166 |
|
10. Partial matching has been split into two forms: PCRE_PARTIAL_SOFT, which is |
| 167 |
|
synonymous with PCRE_PARTIAL, for backwards compatibility, and |
| 168 |
|
PCRE_PARTIAL_HARD, which causes a partial match to supersede a full match, |
| 169 |
|
and may be more useful for multi-segment matching. |
| 170 |
|
|
| 171 |
|
11. Partial matching with pcre_exec() is now more intuitive. A partial match |
| 172 |
|
used to be given if ever the end of the subject was reached; now it is |
| 173 |
|
given only if matching could not proceed because another character was |
| 174 |
|
needed. This makes a difference in some odd cases such as Z(*FAIL) with the |
| 175 |
|
string "Z", which now yields "no match" instead of "partial match". In the |
| 176 |
|
case of pcre_dfa_exec(), "no match" is given if every matching path for the |
| 177 |
|
final character ended with (*FAIL). |
| 178 |
|
|
| 179 |
|
12. Restarting a match using pcre_dfa_exec() after a partial match did not work |
| 180 |
|
if the pattern had a "must contain" character that was already found in the |
| 181 |
|
earlier partial match, unless partial matching was again requested. For |
| 182 |
|
example, with the pattern /dog.(body)?/, the "must contain" character is |
| 183 |
|
"g". If the first part-match was for the string "dog", restarting with |
| 184 |
|
"sbody" failed. This bug has been fixed. |
| 185 |
|
|
| 186 |
|
13. The string returned by pcre_dfa_exec() after a partial match has been |
| 187 |
|
changed so that it starts at the first inspected character rather than the |
| 188 |
|
first character of the match. This makes a difference only if the pattern |
| 189 |
|
starts with a lookbehind assertion or \b or \B (\K is not supported by |
| 190 |
|
pcre_dfa_exec()). It's an incompatible change, but it makes the two |
| 191 |
|
matching functions compatible, and I think it's the right thing to do. |
| 192 |
|
|
| 193 |
|
14. Added a pcredemo man page, created automatically from the pcredemo.c file, |
| 194 |
|
so that the demonstration program is easily available in environments where |
| 195 |
|
PCRE has not been installed from source. |
| 196 |
|
|
| 197 |
|
15. Arranged to add -DPCRE_STATIC to cflags in libpcre.pc, libpcreposix.cp, |
| 198 |
|
libpcrecpp.pc and pcre-config when PCRE is not compiled as a shared |
| 199 |
|
library. |
| 200 |
|
|
| 201 |
|
16. Added REG_UNGREEDY to the pcreposix interface, at the request of a user. |
| 202 |
|
It maps to PCRE_UNGREEDY. It is not, of course, POSIX-compatible, but it |
| 203 |
|
is not the first non-POSIX option to be added. Clearly some people find |
| 204 |
|
these options useful. |
| 205 |
|
|
| 206 |
|
17. If a caller to the POSIX matching function regexec() passes a non-zero |
| 207 |
|
value for nmatch with a NULL value for pmatch, the value of |
| 208 |
|
nmatch is forced to zero. |
| 209 |
|
|
| 210 |
|
18. RunGrepTest did not have a test for the availability of the -u option of |
| 211 |
|
the diff command, as RunTest does. It now checks in the same way as |
| 212 |
|
RunTest, and also checks for the -b option. |
| 213 |
|
|
| 214 |
|
19. If an odd number of negated classes containing just a single character |
| 215 |
|
interposed, within parentheses, between a forward reference to a named |
| 216 |
|
subpattern and the definition of the subpattern, compilation crashed with |
| 217 |
|
an internal error, complaining that it could not find the referenced |
| 218 |
|
subpattern. An example of a crashing pattern is /(?&A)(([^m])(?<A>))/. |
| 219 |
|
[The bug was that it was starting one character too far in when skipping |
| 220 |
|
over the character class, thus treating the ] as data rather than |
| 221 |
|
terminating the class. This meant it could skip too much.] |
| 222 |
|
|
| 223 |
|
20. Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly implement the |
| 224 |
|
/g option in pcretest when the pattern contains \K, which makes it possible |
| 225 |
|
to have an empty string match not at the start, even when the pattern is |
| 226 |
|
anchored. Updated pcretest and pcredemo to use this option. |
| 227 |
|
|
| 228 |
|
21. If the maximum number of capturing subpatterns in a recursion was greater |
| 229 |
|
than the maximum at the outer level, the higher number was returned, but |
| 230 |
|
with unset values at the outer level. The correct (outer level) value is |
| 231 |
|
now given. |
| 232 |
|
|
| 233 |
|
22. If (*ACCEPT) appeared inside capturing parentheses, previous releases of |
| 234 |
|
PCRE did not set those parentheses (unlike Perl). I have now found a way to |
| 235 |
|
make it do so. The string so far is captured, making this feature |
| 236 |
|
compatible with Perl. |
| 237 |
|
|
| 238 |
|
23. The tests have been re-organized, adding tests 11 and 12, to make it |
| 239 |
|
possible to check the Perl 5.10 features against Perl 5.10. |
| 240 |
|
|
| 241 |
|
24. Perl 5.10 allows subroutine calls in lookbehinds, as long as the subroutine |
| 242 |
|
pattern matches a fixed length string. PCRE did not allow this; now it |
| 243 |
|
does. Neither allows recursion. |
| 244 |
|
|
| 245 |
|
25. I finally figured out how to implement a request to provide the minimum |
| 246 |
|
length of subject string that was needed in order to match a given pattern. |
| 247 |
|
(It was back references and recursion that I had previously got hung up |
| 248 |
|
on.) This code has now been added to pcre_study(); it finds a lower bound |
| 249 |
|
to the length of subject needed. It is not necessarily the greatest lower |
| 250 |
|
bound, but using it to avoid searching strings that are too short does give |
| 251 |
|
some useful speed-ups. The value is available to calling programs via |
| 252 |
|
pcre_fullinfo(). |
| 253 |
|
|
| 254 |
|
26. While implementing 25, I discovered to my embarrassment that pcretest had |
| 255 |
|
not been passing the result of pcre_study() to pcre_dfa_exec(), so the |
| 256 |
|
study optimizations had never been tested with that matching function. |
| 257 |
|
Oops. What is worse, even when it was passed study data, there was a bug in |
| 258 |
|
pcre_dfa_exec() that meant it never actually used it. Double oops. There |
| 259 |
|
were also very few tests of studied patterns with pcre_dfa_exec(). |
| 260 |
|
|
| 261 |
|
27. If (?| is used to create subpatterns with duplicate numbers, they are now |
| 262 |
|
allowed to have the same name, even if PCRE_DUPNAMES is not set. However, |
| 263 |
|
on the other side of the coin, they are no longer allowed to have different |
| 264 |
|
names, because these cannot be distinguished in PCRE, and this has caused |
| 265 |
|
confusion. (This is a difference from Perl.) |
| 266 |
|
|
| 267 |
|
28. When duplicate subpattern names are present (necessarily with different |
| 268 |
|
numbers, as required by 27 above), and a test is made by name in a |
| 269 |
|
conditional pattern, either for a subpattern having been matched, or for |
| 270 |
|
recursion in such a pattern, all the associated numbered subpatterns are |
| 271 |
|
tested, and the overall condition is true if the condition is true for any |
| 272 |
|
one of them. This is the way Perl works, and is also more like the way |
| 273 |
|
testing by number works. |
| 274 |
|
|
| 275 |
|
|
| 276 |
Version 7.9 11-Apr-09 |
Version 7.9 11-Apr-09 |
| 277 |
--------------------- |
--------------------- |
Parent Directory
| 
Revision Log
| 
Patch