| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
|
Version 6.6 06-Feb-06 |
| 5 |
|
--------------------- |
| 6 |
|
|
| 7 |
|
1. Change 16(a) for 6.5 broke things, because PCRE_DATA_SCOPE was not defined |
| 8 |
|
in pcreposix.h. I have copied the definition from pcre.h. |
| 9 |
|
|
| 10 |
|
2. Change 25 for 6.5 broke compilation in a build directory out-of-tree |
| 11 |
|
because pcre.h is no longer a built file. |
| 12 |
|
|
| 13 |
|
3. Added Jeff Friedl's additional debugging patches to pcregrep. These are |
| 14 |
|
not normally included in the compiled code. |
| 15 |
|
|
| 16 |
|
|
| 17 |
|
Version 6.5 01-Feb-06 |
| 18 |
|
--------------------- |
| 19 |
|
|
| 20 |
|
1. When using the partial match feature with pcre_dfa_exec(), it was not |
| 21 |
|
anchoring the second and subsequent partial matches at the new starting |
| 22 |
|
point. This could lead to incorrect results. For example, with the pattern |
| 23 |
|
/1234/, partially matching against "123" and then "a4" gave a match. |
| 24 |
|
|
| 25 |
|
2. Changes to pcregrep: |
| 26 |
|
|
| 27 |
|
(a) All non-match returns from pcre_exec() were being treated as failures |
| 28 |
|
to match the line. Now, unless the error is PCRE_ERROR_NOMATCH, an |
| 29 |
|
error message is output. Some extra information is given for the |
| 30 |
|
PCRE_ERROR_MATCHLIMIT and PCRE_ERROR_RECURSIONLIMIT errors, which are |
| 31 |
|
probably the only errors that are likely to be caused by users (by |
| 32 |
|
specifying a regex that has nested indefinite repeats, for instance). |
| 33 |
|
If there are more than 20 of these errors, pcregrep is abandoned. |
| 34 |
|
|
| 35 |
|
(b) A binary zero was treated as data while matching, but terminated the |
| 36 |
|
output line if it was written out. This has been fixed: binary zeroes |
| 37 |
|
are now no different to any other data bytes. |
| 38 |
|
|
| 39 |
|
(c) Whichever of the LC_ALL or LC_CTYPE environment variables is set is |
| 40 |
|
used to set a locale for matching. The --locale=xxxx long option has |
| 41 |
|
been added (no short equivalent) to specify a locale explicitly on the |
| 42 |
|
pcregrep command, overriding the environment variables. |
| 43 |
|
|
| 44 |
|
(d) When -B was used with -n, some line numbers in the output were one less |
| 45 |
|
than they should have been. |
| 46 |
|
|
| 47 |
|
(e) Added the -o (--only-matching) option. |
| 48 |
|
|
| 49 |
|
(f) If -A or -C was used with -c (count only), some lines of context were |
| 50 |
|
accidentally printed for the final match. |
| 51 |
|
|
| 52 |
|
(g) Added the -H (--with-filename) option. |
| 53 |
|
|
| 54 |
|
(h) The combination of options -rh failed to suppress file names for files |
| 55 |
|
that were found from directory arguments. |
| 56 |
|
|
| 57 |
|
(i) Added the -D (--devices) and -d (--directories) options. |
| 58 |
|
|
| 59 |
|
(j) Added the -F (--fixed-strings) option. |
| 60 |
|
|
| 61 |
|
(k) Allow "-" to be used as a file name for -f as well as for a data file. |
| 62 |
|
|
| 63 |
|
(l) Added the --colo(u)r option. |
| 64 |
|
|
| 65 |
|
(m) Added Jeffrey Friedl's -S testing option, but within #ifdefs so that it |
| 66 |
|
is not present by default. |
| 67 |
|
|
| 68 |
|
3. A nasty bug was discovered in the handling of recursive patterns, that is, |
| 69 |
|
items such as (?R) or (?1), when the recursion could match a number of |
| 70 |
|
alternatives. If it matched one of the alternatives, but subsequently, |
| 71 |
|
outside the recursion, there was a failure, the code tried to back up into |
| 72 |
|
the recursion. However, because of the way PCRE is implemented, this is not |
| 73 |
|
possible, and the result was an incorrect result from the match. |
| 74 |
|
|
| 75 |
|
In order to prevent this happening, the specification of recursion has |
| 76 |
|
been changed so that all such subpatterns are automatically treated as |
| 77 |
|
atomic groups. Thus, for example, (?R) is treated as if it were (?>(?R)). |
| 78 |
|
|
| 79 |
|
4. I had overlooked the fact that, in some locales, there are characters for |
| 80 |
|
which isalpha() is true but neither isupper() nor islower() are true. In |
| 81 |
|
the fr_FR locale, for instance, the \xAA and \xBA characters (ordmasculine |
| 82 |
|
and ordfeminine) are like this. This affected the treatment of \w and \W |
| 83 |
|
when they appeared in character classes, but not when they appeared outside |
| 84 |
|
a character class. The bit map for "word" characters is now created |
| 85 |
|
separately from the results of isalnum() instead of just taking it from the |
| 86 |
|
upper, lower, and digit maps. (Plus the underscore character, of course.) |
| 87 |
|
|
| 88 |
|
5. The above bug also affected the handling of POSIX character classes such as |
| 89 |
|
[[:alpha:]] and [[:alnum:]]. These do not have their own bit maps in PCRE's |
| 90 |
|
permanent tables. Instead, the bit maps for such a class were previously |
| 91 |
|
created as the appropriate unions of the upper, lower, and digit bitmaps. |
| 92 |
|
Now they are created by subtraction from the [[:word:]] class, which has |
| 93 |
|
its own bitmap. |
| 94 |
|
|
| 95 |
|
6. The [[:blank:]] character class matches horizontal, but not vertical space. |
| 96 |
|
It is created by subtracting the vertical space characters (\x09, \x0a, |
| 97 |
|
\x0b, \x0c) from the [[:space:]] bitmap. Previously, however, the |
| 98 |
|
subtraction was done in the overall bitmap for a character class, meaning |
| 99 |
|
that a class such as [\x0c[:blank:]] was incorrect because \x0c would not |
| 100 |
|
be recognized. This bug has been fixed. |
| 101 |
|
|
| 102 |
|
7. Patches from the folks at Google: |
| 103 |
|
|
| 104 |
|
(a) pcrecpp.cc: "to handle a corner case that may or may not happen in |
| 105 |
|
real life, but is still worth protecting against". |
| 106 |
|
|
| 107 |
|
(b) pcrecpp.cc: "corrects a bug when negative radixes are used with |
| 108 |
|
regular expressions". |
| 109 |
|
|
| 110 |
|
(c) pcre_scanner.cc: avoid use of std::count() because not all systems |
| 111 |
|
have it. |
| 112 |
|
|
| 113 |
|
(d) Split off pcrecpparg.h from pcrecpp.h and had the former built by |
| 114 |
|
"configure" and the latter not, in order to fix a problem somebody had |
| 115 |
|
with compiling the Arg class on HP-UX. |
| 116 |
|
|
| 117 |
|
(e) Improve the error-handling of the C++ wrapper a little bit. |
| 118 |
|
|
| 119 |
|
(f) New tests for checking recursion limiting. |
| 120 |
|
|
| 121 |
|
8. The pcre_memmove() function, which is used only if the environment does not |
| 122 |
|
have a standard memmove() function (and is therefore rarely compiled), |
| 123 |
|
contained two bugs: (a) use of int instead of size_t, and (b) it was not |
| 124 |
|
returning a result (though PCRE never actually uses the result). |
| 125 |
|
|
| 126 |
|
9. In the POSIX regexec() interface, if nmatch is specified as a ridiculously |
| 127 |
|
large number - greater than INT_MAX/(3*sizeof(int)) - REG_ESPACE is |
| 128 |
|
returned instead of calling malloc() with an overflowing number that would |
| 129 |
|
most likely cause subsequent chaos. |
| 130 |
|
|
| 131 |
|
10. The debugging option of pcretest was not showing the NO_AUTO_CAPTURE flag. |
| 132 |
|
|
| 133 |
|
11. The POSIX flag REG_NOSUB is now supported. When a pattern that was compiled |
| 134 |
|
with this option is matched, the nmatch and pmatch options of regexec() are |
| 135 |
|
ignored. |
| 136 |
|
|
| 137 |
|
12. Added REG_UTF8 to the POSIX interface. This is not defined by POSIX, but is |
| 138 |
|
provided in case anyone wants to the the POSIX interface with UTF-8 |
| 139 |
|
strings. |
| 140 |
|
|
| 141 |
|
13. Added CXXLDFLAGS to the Makefile parameters to provide settings only on the |
| 142 |
|
C++ linking (needed for some HP-UX environments). |
| 143 |
|
|
| 144 |
|
14. Avoid compiler warnings in get_ucpname() when compiled without UCP support |
| 145 |
|
(unused parameter) and in the pcre_printint() function (omitted "default" |
| 146 |
|
switch label when the default is to do nothing). |
| 147 |
|
|
| 148 |
|
15. Added some code to make it possible, when PCRE is compiled as a C++ |
| 149 |
|
library, to replace subject pointers for pcre_exec() with a smart pointer |
| 150 |
|
class, thus making it possible to process discontinuous strings. |
| 151 |
|
|
| 152 |
|
16. The two macros PCRE_EXPORT and PCRE_DATA_SCOPE are confusing, and perform |
| 153 |
|
much the same function. They were added by different people who were trying |
| 154 |
|
to make PCRE easy to compile on non-Unix systems. It has been suggested |
| 155 |
|
that PCRE_EXPORT be abolished now that there is more automatic apparatus |
| 156 |
|
for compiling on Windows systems. I have therefore replaced it with |
| 157 |
|
PCRE_DATA_SCOPE. This is set automatically for Windows; if not set it |
| 158 |
|
defaults to "extern" for C or "extern C" for C++, which works fine on |
| 159 |
|
Unix-like systems. It is now possible to override the value of PCRE_DATA_ |
| 160 |
|
SCOPE with something explicit in config.h. In addition: |
| 161 |
|
|
| 162 |
|
(a) pcreposix.h still had just "extern" instead of either of these macros; |
| 163 |
|
I have replaced it with PCRE_DATA_SCOPE. |
| 164 |
|
|
| 165 |
|
(b) Functions such as _pcre_xclass(), which are internal to the library, |
| 166 |
|
but external in the C sense, all had PCRE_EXPORT in their definitions. |
| 167 |
|
This is apparently wrong for the Windows case, so I have removed it. |
| 168 |
|
(It makes no difference on Unix-like systems.) |
| 169 |
|
|
| 170 |
|
17. Added a new limit, MATCH_LIMIT_RECURSION, which limits the depth of nesting |
| 171 |
|
of recursive calls to match(). This is different to MATCH_LIMIT because |
| 172 |
|
that limits the total number of calls to match(), not all of which increase |
| 173 |
|
the depth of recursion. Limiting the recursion depth limits the amount of |
| 174 |
|
stack (or heap if NO_RECURSE is set) that is used. The default can be set |
| 175 |
|
when PCRE is compiled, and changed at run time. A patch from Google adds |
| 176 |
|
this functionality to the C++ interface. |
| 177 |
|
|
| 178 |
|
18. Changes to the handling of Unicode character properties: |
| 179 |
|
|
| 180 |
|
(a) Updated the table to Unicode 4.1.0. |
| 181 |
|
|
| 182 |
|
(b) Recognize characters that are not in the table as "Cn" (undefined). |
| 183 |
|
|
| 184 |
|
(c) I revised the way the table is implemented to a much improved format |
| 185 |
|
which includes recognition of ranges. It now supports the ranges that |
| 186 |
|
are defined in UnicodeData.txt, and it also amalgamates other |
| 187 |
|
characters into ranges. This has reduced the number of entries in the |
| 188 |
|
table from around 16,000 to around 3,000, thus reducing its size |
| 189 |
|
considerably. I realized I did not need to use a tree structure after |
| 190 |
|
all - a binary chop search is just as efficient. Having reduced the |
| 191 |
|
number of entries, I extended their size from 6 bytes to 8 bytes to |
| 192 |
|
allow for more data. |
| 193 |
|
|
| 194 |
|
(d) Added support for Unicode script names via properties such as \p{Han}. |
| 195 |
|
|
| 196 |
|
19. In UTF-8 mode, a backslash followed by a non-Ascii character was not |
| 197 |
|
matching that character. |
| 198 |
|
|
| 199 |
|
20. When matching a repeated Unicode property with a minimum greater than zero, |
| 200 |
|
(for example \pL{2,}), PCRE could look past the end of the subject if it |
| 201 |
|
reached it while seeking the minimum number of characters. This could |
| 202 |
|
happen only if some of the characters were more than one byte long, because |
| 203 |
|
there is a check for at least the minimum number of bytes. |
| 204 |
|
|
| 205 |
|
21. Refactored the implementation of \p and \P so as to be more general, to |
| 206 |
|
allow for more different types of property in future. This has changed the |
| 207 |
|
compiled form incompatibly. Anybody with saved compiled patterns that use |
| 208 |
|
\p or \P will have to recompile them. |
| 209 |
|
|
| 210 |
|
22. Added "Any" and "L&" to the supported property types. |
| 211 |
|
|
| 212 |
|
23. Recognize \x{...} as a code point specifier, even when not in UTF-8 mode, |
| 213 |
|
but give a compile time error if the value is greater than 0xff. |
| 214 |
|
|
| 215 |
|
24. The man pages for pcrepartial, pcreprecompile, and pcre_compile2 were |
| 216 |
|
accidentally not being installed or uninstalled. |
| 217 |
|
|
| 218 |
|
25. The pcre.h file was built from pcre.h.in, but the only changes that were |
| 219 |
|
made were to insert the current release number. This seemed silly, because |
| 220 |
|
it made things harder for people building PCRE on systems that don't run |
| 221 |
|
"configure". I have turned pcre.h into a distributed file, no longer built |
| 222 |
|
by "configure", with the version identification directly included. There is |
| 223 |
|
no longer a pcre.h.in file. |
| 224 |
|
|
| 225 |
|
However, this change necessitated a change to the pcre-config script as |
| 226 |
|
well. It is built from pcre-config.in, and one of the substitutions was the |
| 227 |
|
release number. I have updated configure.ac so that ./configure now finds |
| 228 |
|
the release number by grepping pcre.h. |
| 229 |
|
|
| 230 |
|
26. Added the ability to run the tests under valgrind. |
| 231 |
|
|
| 232 |
|
|
| 233 |
|
Version 6.4 05-Sep-05 |
| 234 |
|
--------------------- |
| 235 |
|
|
| 236 |
|
1. Change 6.0/10/(l) to pcregrep introduced a bug that caused separator lines |
| 237 |
|
"--" to be printed when multiple files were scanned, even when none of the |
| 238 |
|
-A, -B, or -C options were used. This is not compatible with Gnu grep, so I |
| 239 |
|
consider it to be a bug, and have restored the previous behaviour. |
| 240 |
|
|
| 241 |
|
2. A couple of code tidies to get rid of compiler warnings. |
| 242 |
|
|
| 243 |
|
3. The pcretest program used to cheat by referring to symbols in the library |
| 244 |
|
whose names begin with _pcre_. These are internal symbols that are not |
| 245 |
|
really supposed to be visible externally, and in some environments it is |
| 246 |
|
possible to suppress them. The cheating is now confined to including |
| 247 |
|
certain files from the library's source, which is a bit cleaner. |
| 248 |
|
|
| 249 |
|
4. Renamed pcre.in as pcre.h.in to go with pcrecpp.h.in; it also makes the |
| 250 |
|
file's purpose clearer. |
| 251 |
|
|
| 252 |
|
5. Reorganized pcre_ucp_findchar(). |
| 253 |
|
|
| 254 |
|
|
| 255 |
|
Version 6.3 15-Aug-05 |
| 256 |
|
--------------------- |
| 257 |
|
|
| 258 |
|
1. The file libpcre.pc.in did not have general read permission in the tarball. |
| 259 |
|
|
| 260 |
|
2. There were some problems when building without C++ support: |
| 261 |
|
|
| 262 |
|
(a) If C++ support was not built, "make install" and "make test" still |
| 263 |
|
tried to test it. |
| 264 |
|
|
| 265 |
|
(b) There were problems when the value of CXX was explicitly set. Some |
| 266 |
|
changes have been made to try to fix these, and ... |
| 267 |
|
|
| 268 |
|
(c) --disable-cpp can now be used to explicitly disable C++ support. |
| 269 |
|
|
| 270 |
|
(d) The use of @CPP_OBJ@ directly caused a blank line preceded by a |
| 271 |
|
backslash in a target when C++ was disabled. This confuses some |
| 272 |
|
versions of "make", apparently. Using an intermediate variable solves |
| 273 |
|
this. (Same for CPP_LOBJ.) |
| 274 |
|
|
| 275 |
|
3. $(LINK_FOR_BUILD) now includes $(CFLAGS_FOR_BUILD) and $(LINK) |
| 276 |
|
(non-Windows) now includes $(CFLAGS) because these flags are sometimes |
| 277 |
|
necessary on certain architectures. |
| 278 |
|
|
| 279 |
|
4. Added a setting of -export-symbols-regex to the link command to remove |
| 280 |
|
those symbols that are exported in the C sense, but actually are local |
| 281 |
|
within the library, and not documented. Their names all begin with |
| 282 |
|
"_pcre_". This is not a perfect job, because (a) we have to except some |
| 283 |
|
symbols that pcretest ("illegally") uses, and (b) the facility isn't always |
| 284 |
|
available (and never for static libraries). I have made a note to try to |
| 285 |
|
find a way round (a) in the future. |
| 286 |
|
|
| 287 |
|
|
| 288 |
|
Version 6.2 01-Aug-05 |
| 289 |
|
--------------------- |
| 290 |
|
|
| 291 |
|
1. There was no test for integer overflow of quantifier values. A construction |
| 292 |
|
such as {1111111111111111} would give undefined results. What is worse, if |
| 293 |
|
a minimum quantifier for a parenthesized subpattern overflowed and became |
| 294 |
|
negative, the calculation of the memory size went wrong. This could have |
| 295 |
|
led to memory overwriting. |
| 296 |
|
|
| 297 |
|
2. Building PCRE using VPATH was broken. Hopefully it is now fixed. |
| 298 |
|
|
| 299 |
|
3. Added "b" to the 2nd argument of fopen() in dftables.c, for non-Unix-like |
| 300 |
|
operating environments where this matters. |
| 301 |
|
|
| 302 |
|
4. Applied Giuseppe Maxia's patch to add additional features for controlling |
| 303 |
|
PCRE options from within the C++ wrapper. |
| 304 |
|
|
| 305 |
|
5. Named capturing subpatterns were not being correctly counted when a pattern |
| 306 |
|
was compiled. This caused two problems: (a) If there were more than 100 |
| 307 |
|
such subpatterns, the calculation of the memory needed for the whole |
| 308 |
|
compiled pattern went wrong, leading to an overflow error. (b) Numerical |
| 309 |
|
back references of the form \12, where the number was greater than 9, were |
| 310 |
|
not recognized as back references, even though there were sufficient |
| 311 |
|
previous subpatterns. |
| 312 |
|
|
| 313 |
|
6. Two minor patches to pcrecpp.cc in order to allow it to compile on older |
| 314 |
|
versions of gcc, e.g. 2.95.4. |
| 315 |
|
|
| 316 |
|
|
| 317 |
|
Version 6.1 21-Jun-05 |
| 318 |
|
--------------------- |
| 319 |
|
|
| 320 |
|
1. There was one reference to the variable "posix" in pcretest.c that was not |
| 321 |
|
surrounded by "#if !defined NOPOSIX". |
| 322 |
|
|
| 323 |
|
2. Make it possible to compile pcretest without DFA support, UTF8 support, or |
| 324 |
|
the cross-check on the old pcre_info() function, for the benefit of the |
| 325 |
|
cut-down version of PCRE that is currently imported into Exim. |
| 326 |
|
|
| 327 |
|
3. A (silly) pattern starting with (?i)(?-i) caused an internal space |
| 328 |
|
allocation error. I've done the easy fix, which wastes 2 bytes for sensible |
| 329 |
|
patterns that start (?i) but I don't think that matters. The use of (?i) is |
| 330 |
|
just an example; this all applies to the other options as well. |
| 331 |
|
|
| 332 |
|
4. Since libtool seems to echo the compile commands it is issuing, the output |
| 333 |
|
from "make" can be reduced a bit by putting "@" in front of each libtool |
| 334 |
|
compile command. |
| 335 |
|
|
| 336 |
|
5. Patch from the folks at Google for configure.in to be a bit more thorough |
| 337 |
|
in checking for a suitable C++ installation before trying to compile the |
| 338 |
|
C++ stuff. This should fix a reported problem when a compiler was present, |
| 339 |
|
but no suitable headers. |
| 340 |
|
|
| 341 |
|
6. The man pages all had just "PCRE" as their title. I have changed them to |
| 342 |
|
be the relevant file name. I have also arranged that these names are |
| 343 |
|
retained in the file doc/pcre.txt, which is a concatenation in text format |
| 344 |
|
of all the man pages except the little individual ones for each function. |
| 345 |
|
|
| 346 |
|
7. The NON-UNIX-USE file had not been updated for the different set of source |
| 347 |
|
files that come with release 6. I also added a few comments about the C++ |
| 348 |
|
wrapper. |
| 349 |
|
|
| 350 |
|
|
| 351 |
Version 6.0 07-Jun-05 |
Version 6.0 07-Jun-05 |
| 352 |
--------------------- |
--------------------- |
| 353 |
|
|
Parent Directory
| 
Revision Log
| 
Patch