| 1 |
ChangeLog for PCRE |
ChangeLog for PCRE |
| 2 |
------------------ |
------------------ |
| 3 |
|
|
| 4 |
Version 7.5 12-Nov-07 |
Version 7.7 05-Mar-08 |
| 5 |
|
--------------------- |
| 6 |
|
|
| 7 |
|
1. Applied Craig's patch to sort out a long long problem: "If we can't convert |
| 8 |
|
a string to a long long, pretend we don't even have a long long." This is |
| 9 |
|
done by checking for the strtoq, strtoll, and _strtoi64 functions. |
| 10 |
|
|
| 11 |
|
2. Applied Craig's patch to pcrecpp.cc to restore ABI compatibility with |
| 12 |
|
pre-7.6 versions, which defined a global no_arg variable instead of putting |
| 13 |
|
it in the RE class. (See also #8 below.) |
| 14 |
|
|
| 15 |
|
3. Remove a line of dead code, identified by coverity and reported by Nuno |
| 16 |
|
Lopes. |
| 17 |
|
|
| 18 |
|
4. Fixed two related pcregrep bugs involving -r with --include or --exclude: |
| 19 |
|
|
| 20 |
|
(1) The include/exclude patterns were being applied to the whole pathnames |
| 21 |
|
of files, instead of just to the final components. |
| 22 |
|
|
| 23 |
|
(2) If there was more than one level of directory, the subdirectories were |
| 24 |
|
skipped unless they satisfied the include/exclude conditions. This is |
| 25 |
|
inconsistent with GNU grep (and could even be seen as contrary to the |
| 26 |
|
pcregrep specification - which I improved to make it absolutely clear). |
| 27 |
|
The action now is always to scan all levels of directory, and just |
| 28 |
|
apply the include/exclude patterns to regular files. |
| 29 |
|
|
| 30 |
|
5. Added the --include_dir and --exclude_dir patterns to pcregrep, and used |
| 31 |
|
--exclude_dir in the tests to avoid scanning .svn directories. |
| 32 |
|
|
| 33 |
|
6. Applied Craig's patch to the QuoteMeta function so that it escapes the |
| 34 |
|
NUL character as backslash + 0 rather than backslash + NUL, because PCRE |
| 35 |
|
doesn't support NULs in patterns. |
| 36 |
|
|
| 37 |
|
7. Added some missing "const"s to declarations of static tables in |
| 38 |
|
pcre_compile.c and pcre_dfa_exec.c. |
| 39 |
|
|
| 40 |
|
8. Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was |
| 41 |
|
caused by fix #2 above. (Subsequently also a second patch to fix the |
| 42 |
|
first patch. And a third patch - this was a messy problem.) |
| 43 |
|
|
| 44 |
|
9. Applied Craig's patch to remove the use of push_back(). |
| 45 |
|
|
| 46 |
|
10. Applied Alan Lehotsky's patch to add REG_STARTEND support to the POSIX |
| 47 |
|
matching function regexec(). |
| 48 |
|
|
| 49 |
|
|
| 50 |
|
Version 7.6 28-Jan-08 |
| 51 |
|
--------------------- |
| 52 |
|
|
| 53 |
|
1. A character class containing a very large number of characters with |
| 54 |
|
codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer |
| 55 |
|
overflow. |
| 56 |
|
|
| 57 |
|
2. Patch to cut out the "long long" test in pcrecpp_unittest when |
| 58 |
|
HAVE_LONG_LONG is not defined. |
| 59 |
|
|
| 60 |
|
3. Applied Christian Ehrlicher's patch to update the CMake build files to |
| 61 |
|
bring them up to date and include new features. This patch includes: |
| 62 |
|
|
| 63 |
|
- Fixed PH's badly added libz and libbz2 support. |
| 64 |
|
- Fixed a problem with static linking. |
| 65 |
|
- Added pcredemo. [But later removed - see 7 below.] |
| 66 |
|
- Fixed dftables problem and added an option. |
| 67 |
|
- Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and |
| 68 |
|
HAVE_LONG_LONG. |
| 69 |
|
- Added readline support for pcretest. |
| 70 |
|
- Added an listing of the option settings after cmake has run. |
| 71 |
|
|
| 72 |
|
4. A user submitted a patch to Makefile that makes it easy to create |
| 73 |
|
"pcre.dll" under mingw when using Configure/Make. I added stuff to |
| 74 |
|
Makefile.am that cause it to include this special target, without |
| 75 |
|
affecting anything else. Note that the same mingw target plus all |
| 76 |
|
the other distribution libraries and programs are now supported |
| 77 |
|
when configuring with CMake (see 6 below) instead of with |
| 78 |
|
Configure/Make. |
| 79 |
|
|
| 80 |
|
5. Applied Craig's patch that moves no_arg into the RE class in the C++ code. |
| 81 |
|
This is an attempt to solve the reported problem "pcrecpp::no_arg is not |
| 82 |
|
exported in the Windows port". It has not yet been confirmed that the patch |
| 83 |
|
solves the problem, but it does no harm. |
| 84 |
|
|
| 85 |
|
6. Applied Sheri's patch to CMakeLists.txt to add NON_STANDARD_LIB_PREFIX and |
| 86 |
|
NON_STANDARD_LIB_SUFFIX for dll names built with mingw when configured |
| 87 |
|
with CMake, and also correct the comment about stack recursion. |
| 88 |
|
|
| 89 |
|
7. Remove the automatic building of pcredemo from the ./configure system and |
| 90 |
|
from CMakeLists.txt. The whole idea of pcredemo.c is that it is an example |
| 91 |
|
of a program that users should build themselves after PCRE is installed, so |
| 92 |
|
building it automatically is not really right. What is more, it gave |
| 93 |
|
trouble in some build environments. |
| 94 |
|
|
| 95 |
|
8. Further tidies to CMakeLists.txt from Sheri and Christian. |
| 96 |
|
|
| 97 |
|
|
| 98 |
|
Version 7.5 10-Jan-08 |
| 99 |
--------------------- |
--------------------- |
| 100 |
|
|
| 101 |
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
1. Applied a patch from Craig: "This patch makes it possible to 'ignore' |
| 102 |
values in parens when parsing an RE using the C++ wrapper." |
values in parens when parsing an RE using the C++ wrapper." |
| 103 |
|
|
| 104 |
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
2. Negative specials like \S did not work in character classes in UTF-8 mode. |
| 105 |
Characters greater than 255 were excluded from the class instead of being |
Characters greater than 255 were excluded from the class instead of being |
| 106 |
included. |
included. |
| 107 |
|
|
| 108 |
3. The same bug as (2) above applied to negated POSIX classes such as |
3. The same bug as (2) above applied to negated POSIX classes such as |
| 109 |
[:^space:]. |
[:^space:]. |
| 110 |
|
|
| 111 |
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it |
| 112 |
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
defined or documented. It seems to have been a typo for PCRE_STATIC, so |
| 113 |
I have changed it. |
I have changed it. |
| 114 |
|
|
| 115 |
|
5. The construct (?&) was not diagnosed as a syntax error (it referenced the |
| 116 |
|
first named subpattern) and a construct such as (?&a) would reference the |
| 117 |
|
first named subpattern whose name started with "a" (in other words, the |
| 118 |
|
length check was missing). Both these problems are fixed. "Subpattern name |
| 119 |
|
expected" is now given for (?&) (a zero-length name), and this patch also |
| 120 |
|
makes it give the same error for \k'' (previously it complained that that |
| 121 |
|
was a reference to a non-existent subpattern). |
| 122 |
|
|
| 123 |
|
6. The erroneous patterns (?+-a) and (?-+a) give different error messages; |
| 124 |
|
this is right because (?- can be followed by option settings as well as by |
| 125 |
|
digits. I have, however, made the messages clearer. |
| 126 |
|
|
| 127 |
|
7. Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns |
| 128 |
|
than the number used in the conditional) now cause a compile-time error. |
| 129 |
|
This is actually not compatible with Perl, which accepts such patterns, but |
| 130 |
|
treats the conditional as always being FALSE (as PCRE used to), but it |
| 131 |
|
seems to me that giving a diagnostic is better. |
| 132 |
|
|
| 133 |
|
8. Change "alphameric" to the more common word "alphanumeric" in comments |
| 134 |
|
and messages. |
| 135 |
|
|
| 136 |
|
9. Fix two occurrences of "backslash" in comments that should have been |
| 137 |
|
"backspace". |
| 138 |
|
|
| 139 |
|
10. Remove two redundant lines of code that can never be obeyed (their function |
| 140 |
|
was moved elsewhere). |
| 141 |
|
|
| 142 |
|
11. The program that makes PCRE's Unicode character property table had a bug |
| 143 |
|
which caused it to generate incorrect table entries for sequences of |
| 144 |
|
characters that have the same character type, but are in different scripts. |
| 145 |
|
It amalgamated them into a single range, with the script of the first of |
| 146 |
|
them. In other words, some characters were in the wrong script. There were |
| 147 |
|
thirteen such cases, affecting characters in the following ranges: |
| 148 |
|
|
| 149 |
|
U+002b0 - U+002c1 |
| 150 |
|
U+0060c - U+0060d |
| 151 |
|
U+0061e - U+00612 |
| 152 |
|
U+0064b - U+0065e |
| 153 |
|
U+0074d - U+0076d |
| 154 |
|
U+01800 - U+01805 |
| 155 |
|
U+01d00 - U+01d77 |
| 156 |
|
U+01d9b - U+01dbf |
| 157 |
|
U+0200b - U+0200f |
| 158 |
|
U+030fc - U+030fe |
| 159 |
|
U+03260 - U+0327f |
| 160 |
|
U+0fb46 - U+0fbb1 |
| 161 |
|
U+10450 - U+1049d |
| 162 |
|
|
| 163 |
|
12. The -o option (show only the matching part of a line) for pcregrep was not |
| 164 |
|
compatible with GNU grep in that, if there was more than one match in a |
| 165 |
|
line, it showed only the first of them. It now behaves in the same way as |
| 166 |
|
GNU grep. |
| 167 |
|
|
| 168 |
|
13. If the -o and -v options were combined for pcregrep, it printed a blank |
| 169 |
|
line for every non-matching line. GNU grep prints nothing, and pcregrep now |
| 170 |
|
does the same. The return code can be used to tell if there were any |
| 171 |
|
non-matching lines. |
| 172 |
|
|
| 173 |
|
14. Added --file-offsets and --line-offsets to pcregrep. |
| 174 |
|
|
| 175 |
|
15. The pattern (?=something)(?R) was not being diagnosed as a potentially |
| 176 |
|
infinitely looping recursion. The bug was that positive lookaheads were not |
| 177 |
|
being skipped when checking for a possible empty match (negative lookaheads |
| 178 |
|
and both kinds of lookbehind were skipped). |
| 179 |
|
|
| 180 |
|
16. Fixed two typos in the Windows-only code in pcregrep.c, and moved the |
| 181 |
|
inclusion of <windows.h> to before rather than after the definition of |
| 182 |
|
INVALID_FILE_ATTRIBUTES (patch from David Byron). |
| 183 |
|
|
| 184 |
|
17. Specifying a possessive quantifier with a specific limit for a Unicode |
| 185 |
|
character property caused pcre_compile() to compile bad code, which led at |
| 186 |
|
runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this |
| 187 |
|
are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that |
| 188 |
|
caused the error; without that there was no problem. |
| 189 |
|
|
| 190 |
|
18. Added --enable-pcregrep-libz and --enable-pcregrep-libbz2. |
| 191 |
|
|
| 192 |
|
19. Added --enable-pcretest-libreadline. |
| 193 |
|
|
| 194 |
|
20. In pcrecpp.cc, the variable 'count' was incremented twice in |
| 195 |
|
RE::GlobalReplace(). As a result, the number of replacements returned was |
| 196 |
|
double what it should be. I removed one of the increments, but Craig sent a |
| 197 |
|
later patch that removed the other one (the right fix) and added unit tests |
| 198 |
|
that check the return values (which was not done before). |
| 199 |
|
|
| 200 |
|
21. Several CMake things: |
| 201 |
|
|
| 202 |
|
(1) Arranged that, when cmake is used on Unix, the libraries end up with |
| 203 |
|
the names libpcre and libpcreposix, not just pcre and pcreposix. |
| 204 |
|
|
| 205 |
|
(2) The above change means that pcretest and pcregrep are now correctly |
| 206 |
|
linked with the newly-built libraries, not previously installed ones. |
| 207 |
|
|
| 208 |
|
(3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2. |
| 209 |
|
|
| 210 |
|
22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.* |
| 211 |
|
crashed when matching a string such as a\x{2029}b (note that \x{2029} is a |
| 212 |
|
UTF-8 newline character). The key issue is that the pattern starts .*; |
| 213 |
|
this means that the match must be either at the beginning, or after a |
| 214 |
|
newline. The bug was in the code for advancing after a failed match and |
| 215 |
|
checking that the new position followed a newline. It was not taking |
| 216 |
|
account of UTF-8 characters correctly. |
| 217 |
|
|
| 218 |
|
23. PCRE was behaving differently from Perl in the way it recognized POSIX |
| 219 |
|
character classes. PCRE was not treating the sequence [:...:] as a |
| 220 |
|
character class unless the ... were all letters. Perl, however, seems to |
| 221 |
|
allow any characters between [: and :], though of course it rejects as |
| 222 |
|
unknown any "names" that contain non-letters, because all the known class |
| 223 |
|
names consist only of letters. Thus, Perl gives an error for [[:1234:]], |
| 224 |
|
for example, whereas PCRE did not - it did not recognize a POSIX character |
| 225 |
|
class. This seemed a bit dangerous, so the code has been changed to be |
| 226 |
|
closer to Perl. The behaviour is not identical to Perl, because PCRE will |
| 227 |
|
diagnose an unknown class for, for example, [[:l\ower:]] where Perl will |
| 228 |
|
treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where |
| 229 |
|
Perl does, and where it didn't before. |
| 230 |
|
|
| 231 |
|
24. Rewrite so as to remove the single use of %n from pcregrep because in some |
| 232 |
|
Windows environments %n is disabled by default. |
| 233 |
|
|
| 234 |
|
|
| 235 |
Version 7.4 21-Sep-07 |
Version 7.4 21-Sep-07 |