/[pcre]/code/trunk/ChangeLog
ViewVC logotype

Diff of /code/trunk/ChangeLog

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 275 by ph10, Wed Nov 21 15:35:09 2007 UTC revision 1306 by zherczeg, Mon Apr 1 17:04:17 2013 UTC
# Line 1  Line 1 
1  ChangeLog for PCRE  ChangeLog for PCRE
2  ------------------  ------------------
3    
4  Version 7.5 12-Nov-07  Version 8.33 xx-xxxx-201x
5    -------------------------
6    
7    1.  Added 'U' to some constants that are compared to unsigned integers, to
8        avoid compiler signed/unsigned warnings. Added (int) casts to unsigned
9        variables that are added to signed variables, to ensure the result is
10        signed and can be negated.
11    
12    2.  Applied patch by Daniel Richard G for quashing MSVC warnings to the
13        CMake config files.
14    
15    3.  Revise the creation of config.h.generic so that all boolean macros are
16        #undefined, whereas non-boolean macros are #ifndef/#endif-ed. This makes
17        overriding via -D on the command line possible.
18    
19    4.  Changing the definition of the variable "op" in pcre_exec.c from pcre_uchar
20        to unsigned int is reported to make a quite noticeable speed difference in
21        a specific Windows environment. Testing on Linux did also appear to show
22        some benefit (and it is clearly not harmful). Also fixed the definition of
23        Xop which should be unsigned.
24    
25    5.  Related to (4), changing the definition of the intermediate variable cc
26        in repeated character loops from pcre_uchar to pcre_uint32 also gave speed
27        improvements.
28    
29    6.  Fix forward search in JIT when link size is 3 or greater. Also removed some
30        unnecessary spaces.
31    
32    7.  Adjust autogen.sh and configure.ac to lose warnings given by automake 1.12
33        and later.
34    
35    8.  Fix two buffer over read issues in 16 and 32 bit modes. Affects JIT only.
36    
37    9.  Optimizing fast_forward_start_bits in JIT.
38    
39    10. Adding experimental support for callouts in JIT, and fixing some
40        issues revealed during this work. Namely:
41    
42        (a) Unoptimized capturing brackets incorrectly reset on backtrack.
43    
44        (b) Minimum length was not checked before the matching is started.
45    
46    11. The value of capture_last that is passed to callouts was incorrect in some
47        cases when there was a capture on one path that was subsequently abandoned
48        after a backtrack. Also, the capture_last value is now reset after a
49        recursion, since all captures are also reset in this case.
50    
51    12. The interpreter no longer returns the "too many substrings" error in the
52        case when an overflowing capture is in a branch that is subsequently
53        abandoned after a backtrack.
54    
55    13. In the pathological case when an offset vector of size 2 is used, pcretest
56        now prints out the matched string after a yield of 0 or 1.
57    
58    14. Inlining subpatterns in recursions, when certain conditions are fulfilled.
59        Only supported by the JIT compiler at the moment.
60    
61    15. JIT compiler now supports 32 bit Macs thanks to Lawrence Velazquez.
62    
63    16. Partial matches now set offsets[2] to the "bumpalong" value, that is, the
64        offset of the starting point of the matching process, provided the offsets
65        vector is large enough.
66    
67    17. The \A escape now records a lookbehind value of 1, though its execution
68        does not actually inspect the previous character. This is to ensure that,
69        in partial multi-segment matching, at least one character from the old
70        segment is retained when a new segment is processed. Otherwise, if there
71        are no lookbehinds in the pattern, \A might match incorrectly at the start
72        of a new segment.
73    
74    18. Added some #ifdef __VMS code into pcretest.c to help VMS implementations.
75    
76    19. Redefined some pcre_uchar variables in pcre_exec.c as pcre_uint32; this
77        gives some modest performance improvement in 8-bit mode.
78    
79    20. Added the PCRE-specific property \p{Xuc} for matching characters that can
80        be expressed in certain programming languages using Universal Character
81        Names.
82    
83    21. Unicode validation has been updated in the light of Unicode Corrigendum #9,
84        which points out that "non characters" are not "characters that may not
85        appear in Unicode strings" but rather "characters that are reserved for
86        internal use and have only local meaning".
87    
88    22. When a pattern was compiled with automatic callouts (PCRE_AUTO_CALLOUT) and
89        there was a conditional group that depended on an assertion, if the
90        assertion was false, the callout that immediately followed the alternation
91        in the condition was skipped when pcre_exec() was used for matching.
92    
93    23. Allow an explicit callout to be inserted before an assertion that is the
94        condition for a conditional group, for compatibility with automatic
95        callouts, which always insert a callout at this point.
96    
97    24. In 8.31, (*COMMIT) was confined to within a recursive subpattern. Perl also
98        confines (*SKIP) and (*PRUNE) in the same way, and this has now been done.
99    
100    25. (*PRUNE) is now supported by the JIT compiler.
101    
102    26. Fix infinite loop when /(?<=(*SKIP)ac)a/ is matched against aa.
103    
104    27. Fix the case where there are two or more SKIPs with arguments that may be
105        ignored.
106    
107    28. (*SKIP) is now supported by the JIT compiler.
108    
109    29. (*THEN) is now supported by the JIT compiler.
110    
111    30. Update RunTest with additional test selector options.
112    
113    31. The way PCRE handles backtracking verbs has been changed in two ways.
114    
115        (1) Previously, in something like (*COMMIT)(*SKIP), COMMIT would override
116        SKIP. Now, PCRE acts on whichever backtracking verb is reached first by
117        backtracking. In some cases this makes it more Perl-compatible, but Perl's
118        rather obscure rules do not always do the same thing.
119    
120        (2) Previously, backtracking verbs were confined within assertions. This is
121        no longer the case for positive assertions, except for (*ACCEPT). Again,
122        this sometimes improves Perl compatibility, and sometimes does not.
123    
124    32. A number of tests that were in test 2 because Perl did things differently
125        have been moved to test 1, because either Perl or PCRE has changed, and
126        these tests are now compatible.
127    
128    32. Control verbs are handled in the same way in JIT and interpreter.
129    
130    33. An opening parenthesis in a MARK/PRUNE/SKIP/THEN name in a pattern that
131        contained a forward subroutine reference caused a compile error.
132    
133    34. Auto-detect and optimize limited repetitions in JIT.
134    
135    
136    Version 8.32 30-November-2012
137    -----------------------------
138    
139    1.  Improved JIT compiler optimizations for first character search and single
140        character iterators.
141    
142    2.  Supporting IBM XL C compilers for PPC architectures in the JIT compiler.
143        Patch by Daniel Richard G.
144    
145    3.  Single character iterator optimizations in the JIT compiler.
146    
147    4.  Improved JIT compiler optimizations for character ranges.
148    
149    5.  Rename the "leave" variable names to "quit" to improve WinCE compatibility.
150        Reported by Giuseppe D'Angelo.
151    
152    6.  The PCRE_STARTLINE bit, indicating that a match can occur only at the start
153        of a line, was being set incorrectly in cases where .* appeared inside
154        atomic brackets at the start of a pattern, or where there was a subsequent
155        *PRUNE or *SKIP.
156    
157    7.  Improved instruction cache flush for POWER/PowerPC.
158        Patch by Daniel Richard G.
159    
160    8.  Fixed a number of issues in pcregrep, making it more compatible with GNU
161        grep:
162    
163        (a) There is now no limit to the number of patterns to be matched.
164    
165        (b) An error is given if a pattern is too long.
166    
167        (c) Multiple uses of --exclude, --exclude-dir, --include, and --include-dir
168            are now supported.
169    
170        (d) --exclude-from and --include-from (multiple use) have been added.
171    
172        (e) Exclusions and inclusions now apply to all files and directories, not
173            just to those obtained from scanning a directory recursively.
174    
175        (f) Multiple uses of -f and --file-list are now supported.
176    
177        (g) In a Windows environment, the default for -d has been changed from
178            "read" (the GNU grep default) to "skip", because otherwise the presence
179            of a directory in the file list provokes an error.
180    
181        (h) The documentation has been revised and clarified in places.
182    
183    9.  Improve the matching speed of capturing brackets.
184    
185    10. Changed the meaning of \X so that it now matches a Unicode extended
186        grapheme cluster.
187    
188    11. Patch by Daniel Richard G to the autoconf files to add a macro for sorting
189        out POSIX threads when JIT support is configured.
190    
191    12. Added support for PCRE_STUDY_EXTRA_NEEDED.
192    
193    13. In the POSIX wrapper regcomp() function, setting re_nsub field in the preg
194        structure could go wrong in environments where size_t is not the same size
195        as int.
196    
197    14. Applied user-supplied patch to pcrecpp.cc to allow PCRE_NO_UTF8_CHECK to be
198        set.
199    
200    15. The EBCDIC support had decayed; later updates to the code had included
201        explicit references to (e.g.) \x0a instead of CHAR_LF. There has been a
202        general tidy up of EBCDIC-related issues, and the documentation was also
203        not quite right. There is now a test that can be run on ASCII systems to
204        check some of the EBCDIC-related things (but is it not a full test).
205    
206    16. The new PCRE_STUDY_EXTRA_NEEDED option is now used by pcregrep, resulting
207        in a small tidy to the code.
208    
209    17. Fix JIT tests when UTF is disabled and both 8 and 16 bit mode are enabled.
210    
211    18. If the --only-matching (-o) option in pcregrep is specified multiple
212        times, each one causes appropriate output. For example, -o1 -o2 outputs the
213        substrings matched by the 1st and 2nd capturing parentheses. A separating
214        string can be specified by --om-separator (default empty).
215    
216    19. Improving the first n character searches.
217    
218    20. Turn case lists for horizontal and vertical white space into macros so that
219        they are defined only once.
220    
221    21. This set of changes together give more compatible Unicode case-folding
222        behaviour for characters that have more than one other case when UCP
223        support is available.
224    
225        (a) The Unicode property table now has offsets into a new table of sets of
226            three or more characters that are case-equivalent. The MultiStage2.py
227            script that generates these tables (the pcre_ucd.c file) now scans
228            CaseFolding.txt instead of UnicodeData.txt for character case
229            information.
230    
231        (b) The code for adding characters or ranges of characters to a character
232            class has been abstracted into a generalized function that also handles
233            case-independence. In UTF-mode with UCP support, this uses the new data
234            to handle characters with more than one other case.
235    
236        (c) A bug that is fixed as a result of (b) is that codepoints less than 256
237            whose other case is greater than 256 are now correctly matched
238            caselessly. Previously, the high codepoint matched the low one, but not
239            vice versa.
240    
241        (d) The processing of \h, \H, \v, and \ in character classes now makes use
242            of the new class addition function, using character lists defined as
243            macros alongside the case definitions of 20 above.
244    
245        (e) Caseless back references now work with characters that have more than
246            one other case.
247    
248        (f) General caseless matching of characters with more than one other case
249            is supported.
250    
251    22. Unicode character properties were updated from Unicode 6.2.0
252    
253    23. Improved CMake support under Windows. Patch by Daniel Richard G.
254    
255    24. Add support for 32-bit character strings, and UTF-32
256    
257    25. Major JIT compiler update (code refactoring and bugfixing).
258        Experimental Sparc 32 support is added.
259    
260    26. Applied a modified version of Daniel Richard G's patch to create
261        pcre.h.generic and config.h.generic by "make" instead of in the
262        PrepareRelease script.
263    
264    27. Added a definition for CHAR_NULL (helpful for the z/OS port), and use it in
265        pcre_compile.c when checking for a zero character.
266    
267    28. Introducing a native interface for JIT. Through this interface, the compiled
268        machine code can be directly executed. The purpose of this interface is to
269        provide fast pattern matching, so several sanity checks are not performed.
270        However, feature tests are still performed. The new interface provides
271        1.4x speedup compared to the old one.
272    
273    29. If pcre_exec() or pcre_dfa_exec() was called with a negative value for
274        the subject string length, the error given was PCRE_ERROR_BADOFFSET, which
275        was confusing. There is now a new error PCRE_ERROR_BADLENGTH for this case.
276    
277    30. In 8-bit UTF-8 mode, pcretest failed to give an error for data codepoints
278        greater than 0x7fffffff (which cannot be represented in UTF-8, even under
279        the "old" RFC 2279). Instead, it ended up passing a negative length to
280        pcre_exec().
281    
282    31. Add support for GCC's visibility feature to hide internal functions.
283    
284    32. Running "pcretest -C pcre8" or "pcretest -C pcre16" gave a spurious error
285        "unknown -C option" after outputting 0 or 1.
286    
287    33. There is now support for generating a code coverage report for the test
288        suite in environments where gcc is the compiler and lcov is installed. This
289        is mainly for the benefit of the developers.
290    
291    34. If PCRE is built with --enable-valgrind, certain memory regions are marked
292        unaddressable using valgrind annotations, allowing valgrind to detect
293        invalid memory accesses. This is mainly for the benefit of the developers.
294    
295    25. (*UTF) can now be used to start a pattern in any of the three libraries.
296    
297    26. Give configure error if --enable-cpp but no C++ compiler found.
298    
299    
300    Version 8.31 06-July-2012
301    -------------------------
302    
303    1.  Fixing a wrong JIT test case and some compiler warnings.
304    
305    2.  Removed a bashism from the RunTest script.
306    
307    3.  Add a cast to pcre_exec.c to fix the warning "unary minus operator applied
308        to unsigned type, result still unsigned" that was given by an MS compiler
309        on encountering the code "-sizeof(xxx)".
310    
311    4.  Partial matching support is added to the JIT compiler.
312    
313    5.  Fixed several bugs concerned with partial matching of items that consist
314        of more than one character:
315    
316        (a) /^(..)\1/ did not partially match "aba" because checking references was
317            done on an "all or nothing" basis. This also applied to repeated
318            references.
319    
320        (b) \R did not give a hard partial match if \r was found at the end of the
321            subject.
322    
323        (c) \X did not give a hard partial match after matching one or more
324            characters at the end of the subject.
325    
326        (d) When newline was set to CRLF, a pattern such as /a$/ did not recognize
327            a partial match for the string "\r".
328    
329        (e) When newline was set to CRLF, the metacharacter "." did not recognize
330            a partial match for a CR character at the end of the subject string.
331    
332    6.  If JIT is requested using /S++ or -s++ (instead of just /S+ or -s+) when
333        running pcretest, the text "(JIT)" added to the output whenever JIT is
334        actually used to run the match.
335    
336    7.  Individual JIT compile options can be set in pcretest by following -s+[+]
337        or /S+[+] with a digit between 1 and 7.
338    
339    8.  OP_NOT now supports any UTF character not just single-byte ones.
340    
341    9.  (*MARK) control verb is now supported by the JIT compiler.
342    
343    10. The command "./RunTest list" lists the available tests without actually
344        running any of them. (Because I keep forgetting what they all are.)
345    
346    11. Add PCRE_INFO_MAXLOOKBEHIND.
347    
348    12. Applied a (slightly modified) user-supplied patch that improves performance
349        when the heap is used for recursion (compiled with --disable-stack-for-
350        recursion). Instead of malloc and free for each heap frame each time a
351        logical recursion happens, frames are retained on a chain and re-used where
352        possible. This sometimes gives as much as 30% improvement.
353    
354    13. As documented, (*COMMIT) is now confined to within a recursive subpattern
355        call.
356    
357    14. As documented, (*COMMIT) is now confined to within a positive assertion.
358    
359    15. It is now possible to link pcretest with libedit as an alternative to
360        libreadline.
361    
362    16. (*COMMIT) control verb is now supported by the JIT compiler.
363    
364    17. The Unicode data tables have been updated to Unicode 6.1.0.
365    
366    18. Added --file-list option to pcregrep.
367    
368    19. Added binary file support to pcregrep, including the -a, --binary-files,
369        -I, and --text options.
370    
371    20. The madvise function is renamed for posix_madvise for QNX compatibility
372        reasons. Fixed by Giuseppe D'Angelo.
373    
374    21. Fixed a bug for backward assertions with REVERSE 0 in the JIT compiler.
375    
376    22. Changed the option for creating symbolic links for 16-bit man pages from
377        -s to -sf so that re-installing does not cause issues.
378    
379    23. Support PCRE_NO_START_OPTIMIZE in JIT as (*MARK) support requires it.
380    
381    24. Fixed a very old bug in pcretest that caused errors with restarted DFA
382        matches in certain environments (the workspace was not being correctly
383        retained). Also added to pcre_dfa_exec() a simple plausibility check on
384        some of the workspace data at the beginning of a restart.
385    
386    25. \s*\R was auto-possessifying the \s* when it should not, whereas \S*\R
387        was not doing so when it should - probably a typo introduced by SVN 528
388        (change 8.10/14).
389    
390    26. When PCRE_UCP was not set, \w+\x{c4} was incorrectly auto-possessifying the
391        \w+ when the character tables indicated that \x{c4} was a word character.
392        There were several related cases, all because the tests for doing a table
393        lookup were testing for characters less than 127 instead of 255.
394    
395    27. If a pattern contains capturing parentheses that are not used in a match,
396        their slots in the ovector are set to -1. For those that are higher than
397        any matched groups, this happens at the end of processing. In the case when
398        there were back references that the ovector was too small to contain
399        (causing temporary malloc'd memory to be used during matching), and the
400        highest capturing number was not used, memory off the end of the ovector
401        was incorrectly being set to -1. (It was using the size of the temporary
402        memory instead of the true size.)
403    
404    28. To catch bugs like 27 using valgrind, when pcretest is asked to specify an
405        ovector size, it uses memory at the end of the block that it has got.
406    
407    29. Check for an overlong MARK name and give an error at compile time. The
408        limit is 255 for the 8-bit library and 65535 for the 16-bit library.
409    
410    30. JIT compiler update.
411    
412    31. JIT is now supported on jailbroken iOS devices. Thanks for Ruiger
413        Rill for the patch.
414    
415    32. Put spaces around SLJIT_PRINT_D in the JIT compiler. Required by CXX11.
416    
417    33. Variable renamings in the PCRE-JIT compiler. No functionality change.
418    
419    34. Fixed typos in pcregrep: in two places there was SUPPORT_LIBZ2 instead of
420        SUPPORT_LIBBZ2. This caused a build problem when bzip2 but not gzip (zlib)
421        was enabled.
422    
423    35. Improve JIT code generation for greedy plus quantifier.
424    
425    36. When /((?:a?)*)*c/ or /((?>a?)*)*c/ was matched against "aac", it set group
426        1 to "aa" instead of to an empty string. The bug affected repeated groups
427        that could potentially match an empty string.
428    
429    37. Optimizing single character iterators in JIT.
430    
431    38. Wide characters specified with \uxxxx in JavaScript mode are now subject to
432        the same checks as \x{...} characters in non-JavaScript mode. Specifically,
433        codepoints that are too big for the mode are faulted, and in a UTF mode,
434        disallowed codepoints are also faulted.
435    
436    39. If PCRE was compiled with UTF support, in three places in the DFA
437        matcher there was code that should only have been obeyed in UTF mode, but
438        was being obeyed unconditionally. In 8-bit mode this could cause incorrect
439        processing when bytes with values greater than 127 were present. In 16-bit
440        mode the bug would be provoked by values in the range 0xfc00 to 0xdc00. In
441        both cases the values are those that cannot be the first data item in a UTF
442        character. The three items that might have provoked this were recursions,
443        possessively repeated groups, and atomic groups.
444    
445    40. Ensure that libpcre is explicitly listed in the link commands for pcretest
446        and pcregrep, because some OS require shared objects to be explicitly
447        passed to ld, causing the link step to fail if they are not.
448    
449    41. There were two incorrect #ifdefs in pcre_study.c, meaning that, in 16-bit
450        mode, patterns that started with \h* or \R* might be incorrectly matched.
451    
452    
453    Version 8.30 04-February-2012
454    -----------------------------
455    
456    1.  Renamed "isnumber" as "is_a_number" because in some Mac environments this
457        name is defined in ctype.h.
458    
459    2.  Fixed a bug in fixed-length calculation for lookbehinds that would show up
460        only in quite long subpatterns.
461    
462    3.  Removed the function pcre_info(), which has been obsolete and deprecated
463        since it was replaced by pcre_fullinfo() in February 2000.
464    
465    4.  For a non-anchored pattern, if (*SKIP) was given with a name that did not
466        match a (*MARK), and the match failed at the start of the subject, a
467        reference to memory before the start of the subject could occur. This bug
468        was introduced by fix 17 of release 8.21.
469    
470    5.  A reference to an unset group with zero minimum repetition was giving
471        totally wrong answers (in non-JavaScript-compatibility mode). For example,
472        /(another)?(\1?)test/ matched against "hello world test". This bug was
473        introduced in release 8.13.
474    
475    6.  Add support for 16-bit character strings (a large amount of work involving
476        many changes and refactorings).
477    
478    7.  RunGrepTest failed on msys because \r\n was replaced by whitespace when the
479        command "pattern=`printf 'xxx\r\njkl'`" was run. The pattern is now taken
480        from a file.
481    
482    8.  Ovector size of 2 is also supported by JIT based pcre_exec (the ovector size
483        rounding is not applied in this particular case).
484    
485    9.  The invalid Unicode surrogate codepoints U+D800 to U+DFFF are now rejected
486        if they appear, or are escaped, in patterns.
487    
488    10. Get rid of a number of -Wunused-but-set-variable warnings.
489    
490    11. The pattern /(?=(*:x))(q|)/ matches an empty string, and returns the mark
491        "x". The similar pattern /(?=(*:x))((*:y)q|)/ did not return a mark at all.
492        Oddly, Perl behaves the same way. PCRE has been fixed so that this pattern
493        also returns the mark "x". This bug applied to capturing parentheses,
494        non-capturing parentheses, and atomic parentheses. It also applied to some
495        assertions.
496    
497    12. Stephen Kelly's patch to CMakeLists.txt allows it to parse the version
498        information out of configure.ac instead of relying on pcre.h.generic, which
499        is not stored in the repository.
500    
501    13. Applied Dmitry V. Levin's patch for a more portable method for linking with
502        -lreadline.
503    
504    14. ZH added PCRE_CONFIG_JITTARGET; added its output to pcretest -C.
505    
506    15. Applied Graycode's patch to put the top-level frame on the stack rather
507        than the heap when not using the stack for recursion. This gives a
508        performance improvement in many cases when recursion is not deep.
509    
510    16. Experimental code added to "pcretest -C" to output the stack frame size.
511    
512    
513    Version 8.21 12-Dec-2011
514    ------------------------
515    
516    1.  Updating the JIT compiler.
517    
518    2.  JIT compiler now supports OP_NCREF, OP_RREF and OP_NRREF. New test cases
519        are added as well.
520    
521    3.  Fix cache-flush issue on PowerPC (It is still an experimental JIT port).
522        PCRE_EXTRA_TABLES is not suported by JIT, and should be checked before
523        calling _pcre_jit_exec. Some extra comments are added.
524    
525    4.  (*MARK) settings inside atomic groups that do not contain any capturing
526        parentheses, for example, (?>a(*:m)), were not being passed out. This bug
527        was introduced by change 18 for 8.20.
528    
529    5.  Supporting of \x, \U and \u in JavaScript compatibility mode based on the
530        ECMA-262 standard.
531    
532    6.  Lookbehinds such as (?<=a{2}b) that contained a fixed repetition were
533        erroneously being rejected as "not fixed length" if PCRE_CASELESS was set.
534        This bug was probably introduced by change 9 of 8.13.
535    
536    7.  While fixing 6 above, I noticed that a number of other items were being
537        incorrectly rejected as "not fixed length". This arose partly because newer
538        opcodes had not been added to the fixed-length checking code. I have (a)
539        corrected the bug and added tests for these items, and (b) arranged for an
540        error to occur if an unknown opcode is encountered while checking for fixed
541        length instead of just assuming "not fixed length". The items that were
542        rejected were: (*ACCEPT), (*COMMIT), (*FAIL), (*MARK), (*PRUNE), (*SKIP),
543        (*THEN), \h, \H, \v, \V, and single character negative classes with fixed
544        repetitions, e.g. [^a]{3}, with and without PCRE_CASELESS.
545    
546    8.  A possessively repeated conditional subpattern such as (?(?=c)c|d)++ was
547        being incorrectly compiled and would have given unpredicatble results.
548    
549    9.  A possessively repeated subpattern with minimum repeat count greater than
550        one behaved incorrectly. For example, (A){2,}+ behaved as if it was
551        (A)(A)++ which meant that, after a subsequent mismatch, backtracking into
552        the first (A) could occur when it should not.
553    
554    10. Add a cast and remove a redundant test from the code.
555    
556    11. JIT should use pcre_malloc/pcre_free for allocation.
557    
558    12. Updated pcre-config so that it no longer shows -L/usr/lib, which seems
559        best practice nowadays, and helps with cross-compiling. (If the exec_prefix
560        is anything other than /usr, -L is still shown).
561    
562    13. In non-UTF-8 mode, \C is now supported in lookbehinds and DFA matching.
563    
564    14. Perl does not support \N without a following name in a [] class; PCRE now
565        also gives an error.
566    
567    15. If a forward reference was repeated with an upper limit of around 2000,
568        it caused the error "internal error: overran compiling workspace". The
569        maximum number of forward references (including repeats) was limited by the
570        internal workspace, and dependent on the LINK_SIZE. The code has been
571        rewritten so that the workspace expands (via pcre_malloc) if necessary, and
572        the default depends on LINK_SIZE. There is a new upper limit (for safety)
573        of around 200,000 forward references. While doing this, I also speeded up
574        the filling in of repeated forward references.
575    
576    16. A repeated forward reference in a pattern such as (a)(?2){2}(.) was
577        incorrectly expecting the subject to contain another "a" after the start.
578    
579    17. When (*SKIP:name) is activated without a corresponding (*MARK:name) earlier
580        in the match, the SKIP should be ignored. This was not happening; instead
581        the SKIP was being treated as NOMATCH. For patterns such as
582        /A(*MARK:A)A+(*SKIP:B)Z|AAC/ this meant that the AAC branch was never
583        tested.
584    
585    18. The behaviour of (*MARK), (*PRUNE), and (*THEN) has been reworked and is
586        now much more compatible with Perl, in particular in cases where the result
587        is a non-match for a non-anchored pattern. For example, if
588        /b(*:m)f|a(*:n)w/ is matched against "abc", the non-match returns the name
589        "m", where previously it did not return a name. A side effect of this
590        change is that for partial matches, the last encountered mark name is
591        returned, as for non matches. A number of tests that were previously not
592        Perl-compatible have been moved into the Perl-compatible test files. The
593        refactoring has had the pleasing side effect of removing one argument from
594        the match() function, thus reducing its stack requirements.
595    
596    19. If the /S+ option was used in pcretest to study a pattern using JIT,
597        subsequent uses of /S (without +) incorrectly behaved like /S+.
598    
599    21. Retrieve executable code size support for the JIT compiler and fixing
600        some warnings.
601    
602    22. A caseless match of a UTF-8 character whose other case uses fewer bytes did
603        not work when the shorter character appeared right at the end of the
604        subject string.
605    
606    23. Added some (int) casts to non-JIT modules to reduce warnings on 64-bit
607        systems.
608    
609    24. Added PCRE_INFO_JITSIZE to pass on the value from (21) above, and also
610        output it when the /M option is used in pcretest.
611    
612    25. The CheckMan script was not being included in the distribution. Also, added
613        an explicit "perl" to run Perl scripts from the PrepareRelease script
614        because this is reportedly needed in Windows.
615    
616    26. If study data was being save in a file and studying had not found a set of
617        "starts with" bytes for the pattern, the data written to the file (though
618        never used) was taken from uninitialized memory and so caused valgrind to
619        complain.
620    
621    27. Updated RunTest.bat as provided by Sheri Pierce.
622    
623    28. Fixed a possible uninitialized memory bug in pcre_jit_compile.c.
624    
625    29. Computation of memory usage for the table of capturing group names was
626        giving an unnecessarily large value.
627    
628    
629    Version 8.20 21-Oct-2011
630    ------------------------
631    
632    1.  Change 37 of 8.13 broke patterns like [:a]...[b:] because it thought it had
633        a POSIX class. After further experiments with Perl, which convinced me that
634        Perl has bugs and confusions, a closing square bracket is no longer allowed
635        in a POSIX name. This bug also affected patterns with classes that started
636        with full stops.
637    
638    2.  If a pattern such as /(a)b|ac/ is matched against "ac", there is no
639        captured substring, but while checking the failing first alternative,
640        substring 1 is temporarily captured. If the output vector supplied to
641        pcre_exec() was not big enough for this capture, the yield of the function
642        was still zero ("insufficient space for captured substrings"). This cannot
643        be totally fixed without adding another stack variable, which seems a lot
644        of expense for a edge case. However, I have improved the situation in cases
645        such as /(a)(b)x|abc/ matched against "abc", where the return code
646        indicates that fewer than the maximum number of slots in the ovector have
647        been set.
648    
649    3.  Related to (2) above: when there are more back references in a pattern than
650        slots in the output vector, pcre_exec() uses temporary memory during
651        matching, and copies in the captures as far as possible afterwards. It was
652        using the entire output vector, but this conflicts with the specification
653        that only 2/3 is used for passing back captured substrings. Now it uses
654        only the first 2/3, for compatibility. This is, of course, another edge
655        case.
656    
657    4.  Zoltan Herczeg's just-in-time compiler support has been integrated into the
658        main code base, and can be used by building with --enable-jit. When this is
659        done, pcregrep automatically uses it unless --disable-pcregrep-jit or the
660        runtime --no-jit option is given.
661    
662    5.  When the number of matches in a pcre_dfa_exec() run exactly filled the
663        ovector, the return from the function was zero, implying that there were
664        other matches that did not fit. The correct "exactly full" value is now
665        returned.
666    
667    6.  If a subpattern that was called recursively or as a subroutine contained
668        (*PRUNE) or any other control that caused it to give a non-standard return,
669        invalid errors such as "Error -26 (nested recursion at the same subject
670        position)" or even infinite loops could occur.
671    
672    7.  If a pattern such as /a(*SKIP)c|b(*ACCEPT)|/ was studied, it stopped
673        computing the minimum length on reaching *ACCEPT, and so ended up with the
674        wrong value of 1 rather than 0. Further investigation indicates that
675        computing a minimum subject length in the presence of *ACCEPT is difficult
676        (think back references, subroutine calls), and so I have changed the code
677        so that no minimum is registered for a pattern that contains *ACCEPT.
678    
679    8.  If (*THEN) was present in the first (true) branch of a conditional group,
680        it was not handled as intended. [But see 16 below.]
681    
682    9.  Replaced RunTest.bat and CMakeLists.txt with improved versions provided by
683        Sheri Pierce.
684    
685    10. A pathological pattern such as /(*ACCEPT)a/ was miscompiled, thinking that
686        the first byte in a match must be "a".
687    
688    11. Change 17 for 8.13 increased the recursion depth for patterns like
689        /a(?:.)*?a/ drastically. I've improved things by remembering whether a
690        pattern contains any instances of (*THEN). If it does not, the old
691        optimizations are restored. It would be nice to do this on a per-group
692        basis, but at the moment that is not feasible.
693    
694    12. In some environments, the output of pcretest -C is CRLF terminated. This
695        broke RunTest's code that checks for the link size. A single white space
696        character after the value is now allowed for.
697    
698    13. RunTest now checks for the "fr" locale as well as for "fr_FR" and "french".
699        For "fr", it uses the Windows-specific input and output files.
700    
701    14. If (*THEN) appeared in a group that was called recursively or as a
702        subroutine, it did not work as intended. [But see next item.]
703    
704    15. Consider the pattern /A (B(*THEN)C) | D/ where A, B, C, and D are complex
705        pattern fragments (but not containing any | characters). If A and B are
706        matched, but there is a failure in C so that it backtracks to (*THEN), PCRE
707        was behaving differently to Perl. PCRE backtracked into A, but Perl goes to
708        D. In other words, Perl considers parentheses that do not contain any |
709        characters to be part of a surrounding alternative, whereas PCRE was
710        treading (B(*THEN)C) the same as (B(*THEN)C|(*FAIL)) -- which Perl handles
711        differently. PCRE now behaves in the same way as Perl, except in the case
712        of subroutine/recursion calls such as (?1) which have in any case always
713        been different (but PCRE had them first :-).
714    
715    16. Related to 15 above: Perl does not treat the | in a conditional group as
716        creating alternatives. Such a group is treated in the same way as an
717        ordinary group without any | characters when processing (*THEN). PCRE has
718        been changed to match Perl's behaviour.
719    
720    17. If a user had set PCREGREP_COLO(U)R to something other than 1:31, the
721        RunGrepTest script failed.
722    
723    18. Change 22 for version 13 caused atomic groups to use more stack. This is
724        inevitable for groups that contain captures, but it can lead to a lot of
725        stack use in large patterns. The old behaviour has been restored for atomic
726        groups that do not contain any capturing parentheses.
727    
728    19. If the PCRE_NO_START_OPTIMIZE option was set for pcre_compile(), it did not
729        suppress the check for a minimum subject length at run time. (If it was
730        given to pcre_exec() or pcre_dfa_exec() it did work.)
731    
732    20. Fixed an ASCII-dependent infelicity in pcretest that would have made it
733        fail to work when decoding hex characters in data strings in EBCDIC
734        environments.
735    
736    21. It appears that in at least one Mac OS environment, the isxdigit() function
737        is implemented as a macro that evaluates to its argument more than once,
738        contravening the C 90 Standard (I haven't checked a later standard). There
739        was an instance in pcretest which caused it to go wrong when processing
740        \x{...} escapes in subject strings. The has been rewritten to avoid using
741        things like p++ in the argument of isxdigit().
742    
743    
744    Version 8.13 16-Aug-2011
745    ------------------------
746    
747    1.  The Unicode data tables have been updated to Unicode 6.0.0.
748    
749    2.  Two minor typos in pcre_internal.h have been fixed.
750    
751    3.  Added #include <string.h> to pcre_scanner_unittest.cc, pcrecpp.cc, and
752        pcrecpp_unittest.cc. They are needed for strcmp(), memset(), and strchr()
753        in some environments (e.g. Solaris 10/SPARC using Sun Studio 12U2).
754    
755    4.  There were a number of related bugs in the code for matching backrefences
756        caselessly in UTF-8 mode when codes for the characters concerned were
757        different numbers of bytes. For example, U+023A and U+2C65 are an upper
758        and lower case pair, using 2 and 3 bytes, respectively. The main bugs were:
759        (a) A reference to 3 copies of a 2-byte code matched only 2 of a 3-byte
760        code. (b) A reference to 2 copies of a 3-byte code would not match 2 of a
761        2-byte code at the end of the subject (it thought there wasn't enough data
762        left).
763    
764    5.  Comprehensive information about what went wrong is now returned by
765        pcre_exec() and pcre_dfa_exec() when the UTF-8 string check fails, as long
766        as the output vector has at least 2 elements. The offset of the start of
767        the failing character and a reason code are placed in the vector.
768    
769    6.  When the UTF-8 string check fails for pcre_compile(), the offset that is
770        now returned is for the first byte of the failing character, instead of the
771        last byte inspected. This is an incompatible change, but I hope it is small
772        enough not to be a problem. It makes the returned offset consistent with
773        pcre_exec() and pcre_dfa_exec().
774    
775    7.  pcretest now gives a text phrase as well as the error number when
776        pcre_exec() or pcre_dfa_exec() fails; if the error is a UTF-8 check
777        failure, the offset and reason code are output.
778    
779    8.  When \R was used with a maximizing quantifier it failed to skip backwards
780        over a \r\n pair if the subsequent match failed. Instead, it just skipped
781        back over a single character (\n). This seems wrong (because it treated the
782        two characters as a single entity when going forwards), conflicts with the
783        documentation that \R is equivalent to (?>\r\n|\n|...etc), and makes the
784        behaviour of \R* different to (\R)*, which also seems wrong. The behaviour
785        has been changed.
786    
787    9.  Some internal refactoring has changed the processing so that the handling
788        of the PCRE_CASELESS and PCRE_MULTILINE options is done entirely at compile
789        time (the PCRE_DOTALL option was changed this way some time ago: version
790        7.7 change 16). This has made it possible to abolish the OP_OPT op code,
791        which was always a bit of a fudge. It also means that there is one less
792        argument for the match() function, which reduces its stack requirements
793        slightly. This change also fixes an incompatibility with Perl: the pattern
794        (?i:([^b]))(?1) should not match "ab", but previously PCRE gave a match.
795    
796    10. More internal refactoring has drastically reduced the number of recursive
797        calls to match() for possessively repeated groups such as (abc)++ when
798        using pcre_exec().
799    
800    11. While implementing 10, a number of bugs in the handling of groups were
801        discovered and fixed:
802    
803        (?<=(a)+) was not diagnosed as invalid (non-fixed-length lookbehind).
804        (a|)*(?1) gave a compile-time internal error.
805        ((a|)+)+  did not notice that the outer group could match an empty string.
806        (^a|^)+   was not marked as anchored.
807        (.*a|.*)+ was not marked as matching at start or after a newline.
808    
809    12. Yet more internal refactoring has removed another argument from the match()
810        function. Special calls to this function are now indicated by setting a
811        value in a variable in the "match data" data block.
812    
813    13. Be more explicit in pcre_study() instead of relying on "default" for
814        opcodes that mean there is no starting character; this means that when new
815        ones are added and accidentally left out of pcre_study(), testing should
816        pick them up.
817    
818    14. The -s option of pcretest has been documented for ages as being an old
819        synonym of -m (show memory usage). I have changed it to mean "force study
820        for every regex", that is, assume /S for every regex. This is similar to -i
821        and -d etc. It's slightly incompatible, but I'm hoping nobody is still
822        using it. It makes it easier to run collections of tests with and without
823        study enabled, and thereby test pcre_study() more easily. All the standard
824        tests are now run with and without -s (but some patterns can be marked as
825        "never study" - see 20 below).
826    
827    15. When (*ACCEPT) was used in a subpattern that was called recursively, the
828        restoration of the capturing data to the outer values was not happening
829        correctly.
830    
831    16. If a recursively called subpattern ended with (*ACCEPT) and matched an
832        empty string, and PCRE_NOTEMPTY was set, pcre_exec() thought the whole
833        pattern had matched an empty string, and so incorrectly returned a no
834        match.
835    
836    17. There was optimizing code for the last branch of non-capturing parentheses,
837        and also for the obeyed branch of a conditional subexpression, which used
838        tail recursion to cut down on stack usage. Unfortunately, now that there is
839        the possibility of (*THEN) occurring in these branches, tail recursion is
840        no longer possible because the return has to be checked for (*THEN). These
841        two optimizations have therefore been removed. [But see 8.20/11 above.]
842    
843    18. If a pattern containing \R was studied, it was assumed that \R always
844        matched two bytes, thus causing the minimum subject length to be
845        incorrectly computed because \R can also match just one byte.
846    
847    19. If a pattern containing (*ACCEPT) was studied, the minimum subject length
848        was incorrectly computed.
849    
850    20. If /S is present twice on a test pattern in pcretest input, it now
851        *disables* studying, thereby overriding the use of -s on the command line
852        (see 14 above). This is necessary for one or two tests to keep the output
853        identical in both cases.
854    
855    21. When (*ACCEPT) was used in an assertion that matched an empty string and
856        PCRE_NOTEMPTY was set, PCRE applied the non-empty test to the assertion.
857    
858    22. When an atomic group that contained a capturing parenthesis was
859        successfully matched, but the branch in which it appeared failed, the
860        capturing was not being forgotten if a higher numbered group was later
861        captured. For example, /(?>(a))b|(a)c/ when matching "ac" set capturing
862        group 1 to "a", when in fact it should be unset. This applied to multi-
863        branched capturing and non-capturing groups, repeated or not, and also to
864        positive assertions (capturing in negative assertions does not happen
865        in PCRE) and also to nested atomic groups.
866    
867    23. Add the ++ qualifier feature to pcretest, to show the remainder of the
868        subject after a captured substring, to make it easier to tell which of a
869        number of identical substrings has been captured.
870    
871    24. The way atomic groups are processed by pcre_exec() has been changed so that
872        if they are repeated, backtracking one repetition now resets captured
873        values correctly. For example, if ((?>(a+)b)+aabab) is matched against
874        "aaaabaaabaabab" the value of captured group 2 is now correctly recorded as
875        "aaa". Previously, it would have been "a". As part of this code
876        refactoring, the way recursive calls are handled has also been changed.
877    
878    25. If an assertion condition captured any substrings, they were not passed
879        back unless some other capturing happened later. For example, if
880        (?(?=(a))a) was matched against "a", no capturing was returned.
881    
882    26. When studying a pattern that contained subroutine calls or assertions,
883        the code for finding the minimum length of a possible match was handling
884        direct recursions such as (xxx(?1)|yyy) but not mutual recursions (where
885        group 1 called group 2 while simultaneously a separate group 2 called group
886        1). A stack overflow occurred in this case. I have fixed this by limiting
887        the recursion depth to 10.
888    
889    27. Updated RunTest.bat in the distribution to the version supplied by Tom
890        Fortmann. This supports explicit test numbers on the command line, and has
891        argument validation and error reporting.
892    
893    28. An instance of \X with an unlimited repeat could fail if at any point the
894        first character it looked at was a mark character.
895    
896    29. Some minor code refactoring concerning Unicode properties and scripts
897        should reduce the stack requirement of match() slightly.
898    
899    30. Added the '=' option to pcretest to check the setting of unused capturing
900        slots at the end of the pattern, which are documented as being -1, but are
901        not included in the return count.
902    
903    31. If \k was not followed by a braced, angle-bracketed, or quoted name, PCRE
904        compiled something random. Now it gives a compile-time error (as does
905        Perl).
906    
907    32. A *MARK encountered during the processing of a positive assertion is now
908        recorded and passed back (compatible with Perl).
909    
910    33. If --only-matching or --colour was set on a pcregrep call whose pattern
911        had alternative anchored branches, the search for a second match in a line
912        was done as if at the line start. Thus, for example, /^01|^02/ incorrectly
913        matched the line "0102" twice. The same bug affected patterns that started
914        with a backwards assertion. For example /\b01|\b02/ also matched "0102"
915        twice.
916    
917    34. Previously, PCRE did not allow quantification of assertions. However, Perl
918        does, and because of capturing effects, quantifying parenthesized
919        assertions may at times be useful. Quantifiers are now allowed for
920        parenthesized assertions.
921    
922    35. A minor code tidy in pcre_compile() when checking options for \R usage.
923    
924    36. \g was being checked for fancy things in a character class, when it should
925        just be a literal "g".
926    
927    37. PCRE was rejecting [:a[:digit:]] whereas Perl was not. It seems that the
928        appearance of a nested POSIX class supersedes an apparent external class.
929        For example, [:a[:digit:]b:] matches "a", "b", ":", or a digit. Also,
930        unescaped square brackets may also appear as part of class names. For
931        example, [:a[:abc]b:] gives unknown class "[:abc]b:]". PCRE now behaves
932        more like Perl. (But see 8.20/1 above.)
933    
934    38. PCRE was giving an error for \N with a braced quantifier such as {1,} (this
935        was because it thought it was \N{name}, which is not supported).
936    
937    39. Add minix to OS list not supporting the -S option in pcretest.
938    
939    40. PCRE tries to detect cases of infinite recursion at compile time, but it
940        cannot analyze patterns in sufficient detail to catch mutual recursions
941        such as ((?1))((?2)). There is now a runtime test that gives an error if a
942        subgroup is called recursively as a subpattern for a second time at the
943        same position in the subject string. In previous releases this might have
944        been caught by the recursion limit, or it might have run out of stack.
945    
946    41. A pattern such as /(?(R)a+|(?R)b)/ is quite safe, as the recursion can
947        happen only once. PCRE was, however incorrectly giving a compile time error
948        "recursive call could loop indefinitely" because it cannot analyze the
949        pattern in sufficient detail. The compile time test no longer happens when
950        PCRE is compiling a conditional subpattern, but actual runaway loops are
951        now caught at runtime (see 40 above).
952    
953    42. It seems that Perl allows any characters other than a closing parenthesis
954        to be part of the NAME in (*MARK:NAME) and other backtracking verbs. PCRE
955        has been changed to be the same.
956    
957    43. Updated configure.ac to put in more quoting round AC_LANG_PROGRAM etc. so
958        as not to get warnings when autogen.sh is called. Also changed
959        AC_PROG_LIBTOOL (deprecated) to LT_INIT (the current macro).
960    
961    44. To help people who use pcregrep to scan files containing exceedingly long
962        lines, the following changes have been made:
963    
964        (a) The default value of the buffer size parameter has been increased from
965            8K to 20K. (The actual buffer used is three times this size.)
966    
967        (b) The default can be changed by ./configure --with-pcregrep-bufsize when
968            PCRE is built.
969    
970        (c) A --buffer-size=n option has been added to pcregrep, to allow the size
971            to be set at run time.
972    
973        (d) Numerical values in pcregrep options can be followed by K or M, for
974            example --buffer-size=50K.
975    
976        (e) If a line being scanned overflows pcregrep's buffer, an error is now
977            given and the return code is set to 2.
978    
979    45. Add a pointer to the latest mark to the callout data block.
980    
981    46. The pattern /.(*F)/, when applied to "abc" with PCRE_PARTIAL_HARD, gave a
982        partial match of an empty string instead of no match. This was specific to
983        the use of ".".
984    
985    47. The pattern /f.*/8s, when applied to "for" with PCRE_PARTIAL_HARD, gave a
986        complete match instead of a partial match. This bug was dependent on both
987        the PCRE_UTF8 and PCRE_DOTALL options being set.
988    
989    48. For a pattern such as /\babc|\bdef/ pcre_study() was failing to set up the
990        starting byte set, because \b was not being ignored.
991    
992    
993    Version 8.12 15-Jan-2011
994    ------------------------
995    
996    1.  Fixed some typos in the markup of the man pages, and wrote a script that
997        checks for such things as part of the documentation building process.
998    
999    2.  On a big-endian 64-bit system, pcregrep did not correctly process the
1000        --match-limit and --recursion-limit options (added for 8.11). In
1001        particular, this made one of the standard tests fail. (The integer value
1002        went into the wrong half of a long int.)
1003    
1004    3.  If the --colour option was given to pcregrep with -v (invert match), it
1005        did strange things, either producing crazy output, or crashing. It should,
1006        of course, ignore a request for colour when reporting lines that do not
1007        match.
1008    
1009    4.  Another pcregrep bug caused similar problems if --colour was specified with
1010        -M (multiline) and the pattern match finished with a line ending.
1011    
1012    5.  In pcregrep, when a pattern that ended with a literal newline sequence was
1013        matched in multiline mode, the following line was shown as part of the
1014        match. This seems wrong, so I have changed it.
1015    
1016    6.  Another pcregrep bug in multiline mode, when --colour was specified, caused
1017        the check for further matches in the same line (so they could be coloured)
1018        to overrun the end of the current line. If another match was found, it was
1019        incorrectly shown (and then shown again when found in the next line).
1020    
1021    7.  If pcregrep was compiled under Windows, there was a reference to the
1022        function pcregrep_exit() before it was defined. I am assuming this was
1023        the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was
1024        reported by a user. I've moved the definition above the reference.
1025    
1026    
1027    Version 8.11 10-Dec-2010
1028    ------------------------
1029    
1030    1.  (*THEN) was not working properly if there were untried alternatives prior
1031        to it in the current branch. For example, in ((a|b)(*THEN)(*F)|c..) it
1032        backtracked to try for "b" instead of moving to the next alternative branch
1033        at the same level (in this case, to look for "c"). The Perl documentation
1034        is clear that when (*THEN) is backtracked onto, it goes to the "next
1035        alternative in the innermost enclosing group".
1036    
1037    2.  (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern
1038        such as   (A(*COMMIT)B(*THEN)C|D)  any failure after matching A should
1039        result in overall failure. Similarly, (*COMMIT) now overrides (*PRUNE) and
1040        (*SKIP), (*SKIP) overrides (*PRUNE) and (*THEN), and (*PRUNE) overrides
1041        (*THEN).
1042    
1043    3.  If \s appeared in a character class, it removed the VT character from
1044        the class, even if it had been included by some previous item, for example
1045        in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part
1046        of \s, but is part of the POSIX "space" class.)
1047    
1048    4.  A partial match never returns an empty string (because you can always
1049        match an empty string at the end of the subject); however the checking for
1050        an empty string was starting at the "start of match" point. This has been
1051        changed to the "earliest inspected character" point, because the returned
1052        data for a partial match starts at this character. This means that, for
1053        example, /(?<=abc)def/ gives a partial match for the subject "abc"
1054        (previously it gave "no match").
1055    
1056    5.  Changes have been made to the way PCRE_PARTIAL_HARD affects the matching
1057        of $, \z, \Z, \b, and \B. If the match point is at the end of the string,
1058        previously a full match would be given. However, setting PCRE_PARTIAL_HARD
1059        has an implication that the given string is incomplete (because a partial
1060        match is preferred over a full match). For this reason, these items now
1061        give a partial match in this situation. [Aside: previously, the one case
1062        /t\b/ matched against "cat" with PCRE_PARTIAL_HARD set did return a partial
1063        match rather than a full match, which was wrong by the old rules, but is
1064        now correct.]
1065    
1066    6.  There was a bug in the handling of #-introduced comments, recognized when
1067        PCRE_EXTENDED is set, when PCRE_NEWLINE_ANY and PCRE_UTF8 were also set.
1068        If a UTF-8 multi-byte character included the byte 0x85 (e.g. +U0445, whose
1069        UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when
1070        scanning for the end of the comment. (*Character* 0x85 is an "any" newline,
1071        but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several
1072        places in pcre_compile().
1073    
1074    7.  Related to (6) above, when pcre_compile() was skipping #-introduced
1075        comments when looking ahead for named forward references to subpatterns,
1076        the only newline sequence it recognized was NL. It now handles newlines
1077        according to the set newline convention.
1078    
1079    8.  SunOS4 doesn't have strerror() or strtoul(); pcregrep dealt with the
1080        former, but used strtoul(), whereas pcretest avoided strtoul() but did not
1081        cater for a lack of strerror(). These oversights have been fixed.
1082    
1083    9.  Added --match-limit and --recursion-limit to pcregrep.
1084    
1085    10. Added two casts needed to build with Visual Studio when NO_RECURSE is set.
1086    
1087    11. When the -o option was used, pcregrep was setting a return code of 1, even
1088        when matches were found, and --line-buffered was not being honoured.
1089    
1090    12. Added an optional parentheses number to the -o and --only-matching options
1091        of pcregrep.
1092    
1093    13. Imitating Perl's /g action for multiple matches is tricky when the pattern
1094        can match an empty string. The code to do it in pcretest and pcredemo
1095        needed fixing:
1096    
1097        (a) When the newline convention was "crlf", pcretest got it wrong, skipping
1098            only one byte after an empty string match just before CRLF (this case
1099            just got forgotten; "any" and "anycrlf" were OK).
1100    
1101        (b) The pcretest code also had a bug, causing it to loop forever in UTF-8
1102            mode when an empty string match preceded an ASCII character followed by
1103            a non-ASCII character. (The code for advancing by one character rather
1104            than one byte was nonsense.)
1105    
1106        (c) The pcredemo.c sample program did not have any code at all to handle
1107            the cases when CRLF is a valid newline sequence.
1108    
1109    14. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given
1110        as a starting offset was within the subject string. There is now a new
1111        error, PCRE_ERROR_BADOFFSET, which is returned if the starting offset is
1112        negative or greater than the length of the string. In order to test this,
1113        pcretest is extended to allow the setting of negative starting offsets.
1114    
1115    15. In both pcre_exec() and pcre_dfa_exec() the code for checking that the
1116        starting offset points to the beginning of a UTF-8 character was
1117        unnecessarily clumsy. I tidied it up.
1118    
1119    16. Added PCRE_ERROR_SHORTUTF8 to make it possible to distinguish between a
1120        bad UTF-8 sequence and one that is incomplete when using PCRE_PARTIAL_HARD.
1121    
1122    17. Nobody had reported that the --include_dir option, which was added in
1123        release 7.7 should have been called --include-dir (hyphen, not underscore)
1124        for compatibility with GNU grep. I have changed it to --include-dir, but
1125        left --include_dir as an undocumented synonym, and the same for
1126        --exclude-dir, though that is not available in GNU grep, at least as of
1127        release 2.5.4.
1128    
1129    18. At a user's suggestion, the macros GETCHAR and friends (which pick up UTF-8
1130        characters from a string of bytes) have been redefined so as not to use
1131        loops, in order to improve performance in some environments. At the same
1132        time, I abstracted some of the common code into auxiliary macros to save
1133        repetition (this should not affect the compiled code).
1134    
1135    19. If \c was followed by a multibyte UTF-8 character, bad things happened. A
1136        compile-time error is now given if \c is not followed by an ASCII
1137        character, that is, a byte less than 128. (In EBCDIC mode, the code is
1138        different, and any byte value is allowed.)
1139    
1140    20. Recognize (*NO_START_OPT) at the start of a pattern to set the PCRE_NO_
1141        START_OPTIMIZE option, which is now allowed at compile time - but just
1142        passed through to pcre_exec() or pcre_dfa_exec(). This makes it available
1143        to pcregrep and other applications that have no direct access to PCRE
1144        options. The new /Y option in pcretest sets this option when calling
1145        pcre_compile().
1146    
1147    21. Change 18 of release 8.01 broke the use of named subpatterns for recursive
1148        back references. Groups containing recursive back references were forced to
1149        be atomic by that change, but in the case of named groups, the amount of
1150        memory required was incorrectly computed, leading to "Failed: internal
1151        error: code overflow". This has been fixed.
1152    
1153    22. Some patches to pcre_stringpiece.h, pcre_stringpiece_unittest.cc, and
1154        pcretest.c, to avoid build problems in some Borland environments.
1155    
1156    
1157    Version 8.10 25-Jun-2010
1158    ------------------------
1159    
1160    1.  Added support for (*MARK:ARG) and for ARG additions to PRUNE, SKIP, and
1161        THEN.
1162    
1163    2.  (*ACCEPT) was not working when inside an atomic group.
1164    
1165    3.  Inside a character class, \B is treated as a literal by default, but
1166        faulted if PCRE_EXTRA is set. This mimics Perl's behaviour (the -w option
1167        causes the error). The code is unchanged, but I tidied the documentation.
1168    
1169    4.  Inside a character class, PCRE always treated \R and \X as literals,
1170        whereas Perl faults them if its -w option is set. I have changed PCRE so
1171        that it faults them when PCRE_EXTRA is set.
1172    
1173    5.  Added support for \N, which always matches any character other than
1174        newline. (It is the same as "." when PCRE_DOTALL is not set.)
1175    
1176    6.  When compiling pcregrep with newer versions of gcc which may have
1177        FORTIFY_SOURCE set, several warnings "ignoring return value of 'fwrite',
1178        declared with attribute warn_unused_result" were given. Just casting the
1179        result to (void) does not stop the warnings; a more elaborate fudge is
1180        needed. I've used a macro to implement this.
1181    
1182    7.  Minor change to pcretest.c to avoid a compiler warning.
1183    
1184    8.  Added four artifical Unicode properties to help with an option to make
1185        \s etc use properties (see next item). The new properties are: Xan
1186        (alphanumeric), Xsp (Perl space), Xps (POSIX space), and Xwd (word).
1187    
1188    9.  Added PCRE_UCP to make \b, \d, \s, \w, and certain POSIX character classes
1189        use Unicode properties. (*UCP) at the start of a pattern can be used to set
1190        this option. Modified pcretest to add /W to test this facility. Added
1191        REG_UCP to make it available via the POSIX interface.
1192    
1193    10. Added --line-buffered to pcregrep.
1194    
1195    11. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was
1196        studied, and the match started with a letter with a code point greater than
1197        127 whose first byte was different to the first byte of the other case of
1198        the letter, the other case of this starting letter was not recognized
1199        (#976).
1200    
1201    12. If a pattern that was studied started with a repeated Unicode property
1202        test, for example, \p{Nd}+, there was the theoretical possibility of
1203        setting up an incorrect bitmap of starting bytes, but fortunately it could
1204        not have actually happened in practice until change 8 above was made (it
1205        added property types that matched character-matching opcodes).
1206    
1207    13. pcre_study() now recognizes \h, \v, and \R when constructing a bit map of
1208        possible starting bytes for non-anchored patterns.
1209    
1210    14. Extended the "auto-possessify" feature of pcre_compile(). It now recognizes
1211        \R, and also a number of cases that involve Unicode properties, both
1212        explicit and implicit when PCRE_UCP is set.
1213    
1214    15. If a repeated Unicode property match (e.g. \p{Lu}*) was used with non-UTF-8
1215        input, it could crash or give wrong results if characters with values
1216        greater than 0xc0 were present in the subject string. (Detail: it assumed
1217        UTF-8 input when processing these items.)
1218    
1219    16. Added a lot of (int) casts to avoid compiler warnings in systems where
1220        size_t is 64-bit (#991).
1221    
1222    17. Added a check for running out of memory when PCRE is compiled with
1223        --disable-stack-for-recursion (#990).
1224    
1225    18. If the last data line in a file for pcretest does not have a newline on
1226        the end, a newline was missing in the output.
1227    
1228    19. The default pcre_chartables.c file recognizes only ASCII characters (values
1229        less than 128) in its various bitmaps. However, there is a facility for
1230        generating tables according to the current locale when PCRE is compiled. It
1231        turns out that in some environments, 0x85 and 0xa0, which are Unicode space
1232        characters, are recognized by isspace() and therefore were getting set in
1233        these tables, and indeed these tables seem to approximate to ISO 8859. This
1234        caused a problem in UTF-8 mode when pcre_study() was used to create a list
1235        of bytes that can start a match. For \s, it was including 0x85 and 0xa0,
1236        which of course cannot start UTF-8 characters. I have changed the code so
1237        that only real ASCII characters (less than 128) and the correct starting
1238        bytes for UTF-8 encodings are set for characters greater than 127 when in
1239        UTF-8 mode. (When PCRE_UCP is set - see 9 above - the code is different
1240        altogether.)
1241    
1242    20. Added the /T option to pcretest so as to be able to run tests with non-
1243        standard character tables, thus making it possible to include the tests
1244        used for 19 above in the standard set of tests.
1245    
1246    21. A pattern such as (?&t)(?#()(?(DEFINE)(?<t>a)) which has a forward
1247        reference to a subpattern the other side of a comment that contains an
1248        opening parenthesis caused either an internal compiling error, or a
1249        reference to the wrong subpattern.
1250    
1251    
1252    Version 8.02 19-Mar-2010
1253    ------------------------
1254    
1255    1.  The Unicode data tables have been updated to Unicode 5.2.0.
1256    
1257    2.  Added the option --libs-cpp to pcre-config, but only when C++ support is
1258        configured.
1259    
1260    3.  Updated the licensing terms in the pcregexp.pas file, as agreed with the
1261        original author of that file, following a query about its status.
1262    
1263    4.  On systems that do not have stdint.h (e.g. Solaris), check for and include
1264        inttypes.h instead. This fixes a bug that was introduced by change 8.01/8.
1265    
1266    5.  A pattern such as (?&t)*+(?(DEFINE)(?<t>.)) which has a possessive
1267        quantifier applied to a forward-referencing subroutine call, could compile
1268        incorrect code or give the error "internal error: previously-checked
1269        referenced subpattern not found".
1270    
1271    6.  Both MS Visual Studio and Symbian OS have problems with initializing
1272        variables to point to external functions. For these systems, therefore,
1273        pcre_malloc etc. are now initialized to local functions that call the
1274        relevant global functions.
1275    
1276    7.  There were two entries missing in the vectors called coptable and poptable
1277        in pcre_dfa_exec.c. This could lead to memory accesses outsize the vectors.
1278        I've fixed the data, and added a kludgy way of testing at compile time that
1279        the lengths are correct (equal to the number of opcodes).
1280    
1281    8.  Following on from 7, I added a similar kludge to check the length of the
1282        eint vector in pcreposix.c.
1283    
1284    9.  Error texts for pcre_compile() are held as one long string to avoid too
1285        much relocation at load time. To find a text, the string is searched,
1286        counting zeros. There was no check for running off the end of the string,
1287        which could happen if a new error number was added without updating the
1288        string.
1289    
1290    10. \K gave a compile-time error if it appeared in a lookbehind assersion.
1291    
1292    11. \K was not working if it appeared in an atomic group or in a group that
1293        was called as a "subroutine", or in an assertion. Perl 5.11 documents that
1294        \K is "not well defined" if used in an assertion. PCRE now accepts it if
1295        the assertion is positive, but not if it is negative.
1296    
1297    12. Change 11 fortuitously reduced the size of the stack frame used in the
1298        "match()" function of pcre_exec.c by one pointer. Forthcoming
1299        implementation of support for (*MARK) will need an extra pointer on the
1300        stack; I have reserved it now, so that the stack frame size does not
1301        decrease.
1302    
1303    13. A pattern such as (?P<L1>(?P<L2>0)|(?P>L2)(?P>L1)) in which the only other
1304        item in branch that calls a recursion is a subroutine call - as in the
1305        second branch in the above example - was incorrectly given the compile-
1306        time error "recursive call could loop indefinitely" because pcre_compile()
1307        was not correctly checking the subroutine for matching a non-empty string.
1308    
1309    14. The checks for overrunning compiling workspace could trigger after an
1310        overrun had occurred. This is a "should never occur" error, but it can be
1311        triggered by pathological patterns such as hundreds of nested parentheses.
1312        The checks now trigger 100 bytes before the end of the workspace.
1313    
1314    15. Fix typo in configure.ac: "srtoq" should be "strtoq".
1315    
1316    
1317    Version 8.01 19-Jan-2010
1318    ------------------------
1319    
1320    1.  If a pattern contained a conditional subpattern with only one branch (in
1321        particular, this includes all (*DEFINE) patterns), a call to pcre_study()
1322        computed the wrong minimum data length (which is of course zero for such
1323        subpatterns). This could cause incorrect "no match" results.
1324    
1325    2.  For patterns such as (?i)a(?-i)b|c where an option setting at the start of
1326        the pattern is reset in the first branch, pcre_compile() failed with
1327        "internal error: code overflow at offset...". This happened only when
1328        the reset was to the original external option setting. (An optimization
1329        abstracts leading options settings into an external setting, which was the
1330        cause of this.)
1331    
1332    3.  A pattern such as ^(?!a(*SKIP)b) where a negative assertion contained one
1333        of the verbs SKIP, PRUNE, or COMMIT, did not work correctly. When the
1334        assertion pattern did not match (meaning that the assertion was true), it
1335        was incorrectly treated as false if the SKIP had been reached during the
1336        matching. This also applied to assertions used as conditions.
1337    
1338    4.  If an item that is not supported by pcre_dfa_exec() was encountered in an
1339        assertion subpattern, including such a pattern used as a condition,
1340        unpredictable results occurred, instead of the error return
1341        PCRE_ERROR_DFA_UITEM.
1342    
1343    5.  The C++ GlobalReplace function was not working like Perl for the special
1344        situation when an empty string is matched. It now does the fancy magic
1345        stuff that is necessary.
1346    
1347    6.  In pcre_internal.h, obsolete includes to setjmp.h and stdarg.h have been
1348        removed. (These were left over from very, very early versions of PCRE.)
1349    
1350    7.  Some cosmetic changes to the code to make life easier when compiling it
1351        as part of something else:
1352    
1353        (a) Change DEBUG to PCRE_DEBUG.
1354    
1355        (b) In pcre_compile(), rename the member of the "branch_chain" structure
1356            called "current" as "current_branch", to prevent a collision with the
1357            Linux macro when compiled as a kernel module.
1358    
1359        (c) In pcre_study(), rename the function set_bit() as set_table_bit(), to
1360            prevent a collision with the Linux macro when compiled as a kernel
1361            module.
1362    
1363    8.  In pcre_compile() there are some checks for integer overflows that used to
1364        cast potentially large values to (double). This has been changed to that
1365        when building, a check for int64_t is made, and if it is found, it is used
1366        instead, thus avoiding the use of floating point arithmetic. (There is no
1367        other use of FP in PCRE.) If int64_t is not found, the fallback is to
1368        double.
1369    
1370    9.  Added two casts to avoid signed/unsigned warnings from VS Studio Express
1371        2005 (difference between two addresses compared to an unsigned value).
1372    
1373    10. Change the standard AC_CHECK_LIB test for libbz2 in configure.ac to a
1374        custom one, because of the following reported problem in Windows:
1375    
1376          - libbz2 uses the Pascal calling convention (WINAPI) for the functions
1377              under Win32.
1378          - The standard autoconf AC_CHECK_LIB fails to include "bzlib.h",
1379              therefore missing the function definition.
1380          - The compiler thus generates a "C" signature for the test function.
1381          - The linker fails to find the "C" function.
1382          - PCRE fails to configure if asked to do so against libbz2.
1383    
1384    11. When running libtoolize from libtool-2.2.6b as part of autogen.sh, these
1385        messages were output:
1386    
1387          Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
1388          rerunning libtoolize, to keep the correct libtool macros in-tree.
1389          Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
1390    
1391        I have done both of these things.
1392    
1393    12. Although pcre_dfa_exec() does not use nearly as much stack as pcre_exec()
1394        most of the time, it *can* run out if it is given a pattern that contains a
1395        runaway infinite recursion. I updated the discussion in the pcrestack man
1396        page.
1397    
1398    13. Now that we have gone to the x.xx style of version numbers, the minor
1399        version may start with zero. Using 08 or 09 is a bad idea because users
1400        might check the value of PCRE_MINOR in their code, and 08 or 09 may be
1401        interpreted as invalid octal numbers. I've updated the previous comment in
1402        configure.ac, and also added a check that gives an error if 08 or 09 are
1403        used.
1404    
1405    14. Change 8.00/11 was not quite complete: code had been accidentally omitted,
1406        causing partial matching to fail when the end of the subject matched \W
1407        in a UTF-8 pattern where \W was quantified with a minimum of 3.
1408    
1409    15. There were some discrepancies between the declarations in pcre_internal.h
1410        of _pcre_is_newline(), _pcre_was_newline(), and _pcre_valid_utf8() and
1411        their definitions. The declarations used "const uschar *" and the
1412        definitions used USPTR. Even though USPTR is normally defined as "const
1413        unsigned char *" (and uschar is typedeffed as "unsigned char"), it was
1414        reported that: "This difference in casting confuses some C++ compilers, for
1415        example, SunCC recognizes above declarations as different functions and
1416        generates broken code for hbpcre." I have changed the declarations to use
1417        USPTR.
1418    
1419    16. GNU libtool is named differently on some systems. The autogen.sh script now
1420        tries several variants such as glibtoolize (MacOSX) and libtoolize1x
1421        (FreeBSD).
1422    
1423    17. Applied Craig's patch that fixes an HP aCC compile error in pcre 8.00
1424        (strtoXX undefined when compiling pcrecpp.cc). The patch contains this
1425        comment: "Figure out how to create a longlong from a string: strtoll and
1426        equivalent. It's not enough to call AC_CHECK_FUNCS: hpux has a strtoll, for
1427        instance, but it only takes 2 args instead of 3!"
1428    
1429    18. A subtle bug concerned with back references has been fixed by a change of
1430        specification, with a corresponding code fix. A pattern such as
1431        ^(xa|=?\1a)+$ which contains a back reference inside the group to which it
1432        refers, was giving matches when it shouldn't. For example, xa=xaaa would
1433        match that pattern. Interestingly, Perl (at least up to 5.11.3) has the
1434        same bug. Such groups have to be quantified to be useful, or contained
1435        inside another quantified group. (If there's no repetition, the reference
1436        can never match.) The problem arises because, having left the group and
1437        moved on to the rest of the pattern, a later failure that backtracks into
1438        the group uses the captured value from the final iteration of the group
1439        rather than the correct earlier one. I have fixed this in PCRE by forcing
1440        any group that contains a reference to itself to be an atomic group; that
1441        is, there cannot be any backtracking into it once it has completed. This is
1442        similar to recursive and subroutine calls.
1443    
1444    
1445    Version 8.00 19-Oct-09
1446    ----------------------
1447    
1448    1.  The table for translating pcre_compile() error codes into POSIX error codes
1449        was out-of-date, and there was no check on the pcre_compile() error code
1450        being within the table. This could lead to an OK return being given in
1451        error.
1452    
1453    2.  Changed the call to open a subject file in pcregrep from fopen(pathname,
1454        "r") to fopen(pathname, "rb"), which fixed a problem with some of the tests
1455        in a Windows environment.
1456    
1457    3.  The pcregrep --count option prints the count for each file even when it is
1458        zero, as does GNU grep. However, pcregrep was also printing all files when
1459        --files-with-matches was added. Now, when both options are given, it prints
1460        counts only for those files that have at least one match. (GNU grep just
1461        prints the file name in this circumstance, but including the count seems
1462        more useful - otherwise, why use --count?) Also ensured that the
1463        combination -clh just lists non-zero counts, with no names.
1464    
1465    4.  The long form of the pcregrep -F option was incorrectly implemented as
1466        --fixed_strings instead of --fixed-strings. This is an incompatible change,
1467        but it seems right to fix it, and I didn't think it was worth preserving
1468        the old behaviour.
1469    
1470    5.  The command line items --regex=pattern and --regexp=pattern were not
1471        recognized by pcregrep, which required --regex pattern or --regexp pattern
1472        (with a space rather than an '='). The man page documented the '=' forms,
1473        which are compatible with GNU grep; these now work.
1474    
1475    6.  No libpcreposix.pc file was created for pkg-config; there was just
1476        libpcre.pc and libpcrecpp.pc. The omission has been rectified.
1477    
1478    7.  Added #ifndef SUPPORT_UCP into the pcre_ucd.c module, to reduce its size
1479        when UCP support is not needed, by modifying the Python script that
1480        generates it from Unicode data files. This should not matter if the module
1481        is correctly used as a library, but I received one complaint about 50K of
1482        unwanted data. My guess is that the person linked everything into his
1483        program rather than using a library. Anyway, it does no harm.
1484    
1485    8.  A pattern such as /\x{123}{2,2}+/8 was incorrectly compiled; the trigger
1486        was a minimum greater than 1 for a wide character in a possessive
1487        repetition. The same bug could also affect patterns like /(\x{ff}{0,2})*/8
1488        which had an unlimited repeat of a nested, fixed maximum repeat of a wide
1489        character. Chaos in the form of incorrect output or a compiling loop could
1490        result.
1491    
1492    9.  The restrictions on what a pattern can contain when partial matching is
1493        requested for pcre_exec() have been removed. All patterns can now be
1494        partially matched by this function. In addition, if there are at least two
1495        slots in the offset vector, the offset of the earliest inspected character
1496        for the match and the offset of the end of the subject are set in them when
1497        PCRE_ERROR_PARTIAL is returned.
1498    
1499    10. Partial matching has been split into two forms: PCRE_PARTIAL_SOFT, which is
1500        synonymous with PCRE_PARTIAL, for backwards compatibility, and
1501        PCRE_PARTIAL_HARD, which causes a partial match to supersede a full match,
1502        and may be more useful for multi-segment matching.
1503    
1504    11. Partial matching with pcre_exec() is now more intuitive. A partial match
1505        used to be given if ever the end of the subject was reached; now it is
1506        given only if matching could not proceed because another character was
1507        needed. This makes a difference in some odd cases such as Z(*FAIL) with the
1508        string "Z", which now yields "no match" instead of "partial match". In the
1509        case of pcre_dfa_exec(), "no match" is given if every matching path for the
1510        final character ended with (*FAIL).
1511    
1512    12. Restarting a match using pcre_dfa_exec() after a partial match did not work
1513        if the pattern had a "must contain" character that was already found in the
1514        earlier partial match, unless partial matching was again requested. For
1515        example, with the pattern /dog.(body)?/, the "must contain" character is
1516        "g". If the first part-match was for the string "dog", restarting with
1517        "sbody" failed. This bug has been fixed.
1518    
1519    13. The string returned by pcre_dfa_exec() after a partial match has been
1520        changed so that it starts at the first inspected character rather than the
1521        first character of the match. This makes a difference only if the pattern
1522        starts with a lookbehind assertion or \b or \B (\K is not supported by
1523        pcre_dfa_exec()). It's an incompatible change, but it makes the two
1524        matching functions compatible, and I think it's the right thing to do.
1525    
1526    14. Added a pcredemo man page, created automatically from the pcredemo.c file,
1527        so that the demonstration program is easily available in environments where
1528        PCRE has not been installed from source.
1529    
1530    15. Arranged to add -DPCRE_STATIC to cflags in libpcre.pc, libpcreposix.cp,
1531        libpcrecpp.pc and pcre-config when PCRE is not compiled as a shared
1532        library.
1533    
1534    16. Added REG_UNGREEDY to the pcreposix interface, at the request of a user.
1535        It maps to PCRE_UNGREEDY. It is not, of course, POSIX-compatible, but it
1536        is not the first non-POSIX option to be added. Clearly some people find
1537        these options useful.
1538    
1539    17. If a caller to the POSIX matching function regexec() passes a non-zero
1540        value for nmatch with a NULL value for pmatch, the value of
1541        nmatch is forced to zero.
1542    
1543    18. RunGrepTest did not have a test for the availability of the -u option of
1544        the diff command, as RunTest does. It now checks in the same way as
1545        RunTest, and also checks for the -b option.
1546    
1547    19. If an odd number of negated classes containing just a single character
1548        interposed, within parentheses, between a forward reference to a named
1549        subpattern and the definition of the subpattern, compilation crashed with
1550        an internal error, complaining that it could not find the referenced
1551        subpattern. An example of a crashing pattern is /(?&A)(([^m])(?<A>))/.
1552        [The bug was that it was starting one character too far in when skipping
1553        over the character class, thus treating the ] as data rather than
1554        terminating the class. This meant it could skip too much.]
1555    
1556    20. Added PCRE_NOTEMPTY_ATSTART in order to be able to correctly implement the
1557        /g option in pcretest when the pattern contains \K, which makes it possible
1558        to have an empty string match not at the start, even when the pattern is
1559        anchored. Updated pcretest and pcredemo to use this option.
1560    
1561    21. If the maximum number of capturing subpatterns in a recursion was greater
1562        than the maximum at the outer level, the higher number was returned, but
1563        with unset values at the outer level. The correct (outer level) value is
1564        now given.
1565    
1566    22. If (*ACCEPT) appeared inside capturing parentheses, previous releases of
1567        PCRE did not set those parentheses (unlike Perl). I have now found a way to
1568        make it do so. The string so far is captured, making this feature
1569        compatible with Perl.
1570    
1571    23. The tests have been re-organized, adding tests 11 and 12, to make it
1572        possible to check the Perl 5.10 features against Perl 5.10.
1573    
1574    24. Perl 5.10 allows subroutine calls in lookbehinds, as long as the subroutine
1575        pattern matches a fixed length string. PCRE did not allow this; now it
1576        does. Neither allows recursion.
1577    
1578    25. I finally figured out how to implement a request to provide the minimum
1579        length of subject string that was needed in order to match a given pattern.
1580        (It was back references and recursion that I had previously got hung up
1581        on.) This code has now been added to pcre_study(); it finds a lower bound
1582        to the length of subject needed. It is not necessarily the greatest lower
1583        bound, but using it to avoid searching strings that are too short does give
1584        some useful speed-ups. The value is available to calling programs via
1585        pcre_fullinfo().
1586    
1587    26. While implementing 25, I discovered to my embarrassment that pcretest had
1588        not been passing the result of pcre_study() to pcre_dfa_exec(), so the
1589        study optimizations had never been tested with that matching function.
1590        Oops. What is worse, even when it was passed study data, there was a bug in
1591        pcre_dfa_exec() that meant it never actually used it. Double oops. There
1592        were also very few tests of studied patterns with pcre_dfa_exec().
1593    
1594    27. If (?| is used to create subpatterns with duplicate numbers, they are now
1595        allowed to have the same name, even if PCRE_DUPNAMES is not set. However,
1596        on the other side of the coin, they are no longer allowed to have different
1597        names, because these cannot be distinguished in PCRE, and this has caused
1598        confusion. (This is a difference from Perl.)
1599    
1600    28. When duplicate subpattern names are present (necessarily with different
1601        numbers, as required by 27 above), and a test is made by name in a
1602        conditional pattern, either for a subpattern having been matched, or for
1603        recursion in such a pattern, all the associated numbered subpatterns are
1604        tested, and the overall condition is true if the condition is true for any
1605        one of them. This is the way Perl works, and is also more like the way
1606        testing by number works.
1607    
1608    
1609    Version 7.9 11-Apr-09
1610    ---------------------
1611    
1612    1.  When building with support for bzlib/zlib (pcregrep) and/or readline
1613        (pcretest), all targets were linked against these libraries. This included
1614        libpcre, libpcreposix, and libpcrecpp, even though they do not use these
1615        libraries. This caused unwanted dependencies to be created. This problem
1616        has been fixed, and now only pcregrep is linked with bzlib/zlib and only
1617        pcretest is linked with readline.
1618    
1619    2.  The "typedef int BOOL" in pcre_internal.h that was included inside the
1620        "#ifndef FALSE" condition by an earlier change (probably 7.8/18) has been
1621        moved outside it again, because FALSE and TRUE are already defined in AIX,
1622        but BOOL is not.
1623    
1624    3.  The pcre_config() function was treating the PCRE_MATCH_LIMIT and
1625        PCRE_MATCH_LIMIT_RECURSION values as ints, when they should be long ints.
1626    
1627    4.  The pcregrep documentation said spaces were inserted as well as colons (or
1628        hyphens) following file names and line numbers when outputting matching
1629        lines. This is not true; no spaces are inserted. I have also clarified the
1630        wording for the --colour (or --color) option.
1631    
1632    5.  In pcregrep, when --colour was used with -o, the list of matching strings
1633        was not coloured; this is different to GNU grep, so I have changed it to be
1634        the same.
1635    
1636    6.  When --colo(u)r was used in pcregrep, only the first matching substring in
1637        each matching line was coloured. Now it goes on to look for further matches
1638        of any of the test patterns, which is the same behaviour as GNU grep.
1639    
1640    7.  A pattern that could match an empty string could cause pcregrep to loop; it
1641        doesn't make sense to accept an empty string match in pcregrep, so I have
1642        locked it out (using PCRE's PCRE_NOTEMPTY option). By experiment, this
1643        seems to be how GNU grep behaves.
1644    
1645    8.  The pattern (?(?=.*b)b|^) was incorrectly compiled as "match must be at
1646        start or after a newline", because the conditional assertion was not being
1647        correctly handled. The rule now is that both the assertion and what follows
1648        in the first alternative must satisfy the test.
1649    
1650    9.  If auto-callout was enabled in a pattern with a conditional group whose
1651        condition was an assertion, PCRE could crash during matching, both with
1652        pcre_exec() and pcre_dfa_exec().
1653    
1654    10. The PCRE_DOLLAR_ENDONLY option was not working when pcre_dfa_exec() was
1655        used for matching.
1656    
1657    11. Unicode property support in character classes was not working for
1658        characters (bytes) greater than 127 when not in UTF-8 mode.
1659    
1660    12. Added the -M command line option to pcretest.
1661    
1662    14. Added the non-standard REG_NOTEMPTY option to the POSIX interface.
1663    
1664    15. Added the PCRE_NO_START_OPTIMIZE match-time option.
1665    
1666    16. Added comments and documentation about mis-use of no_arg in the C++
1667        wrapper.
1668    
1669    17. Implemented support for UTF-8 encoding in EBCDIC environments, a patch
1670        from Martin Jerabek that uses macro names for all relevant character and
1671        string constants.
1672    
1673    18. Added to pcre_internal.h two configuration checks: (a) If both EBCDIC and
1674        SUPPORT_UTF8 are set, give an error; (b) If SUPPORT_UCP is set without
1675        SUPPORT_UTF8, define SUPPORT_UTF8. The "configure" script handles both of
1676        these, but not everybody uses configure.
1677    
1678    19. A conditional group that had only one branch was not being correctly
1679        recognized as an item that could match an empty string. This meant that an
1680        enclosing group might also not be so recognized, causing infinite looping
1681        (and probably a segfault) for patterns such as ^"((?(?=[a])[^"])|b)*"$
1682        with the subject "ab", where knowledge that the repeated group can match
1683        nothing is needed in order to break the loop.
1684    
1685    20. If a pattern that was compiled with callouts was matched using pcre_dfa_
1686        exec(), but without supplying a callout function, matching went wrong.
1687    
1688    21. If PCRE_ERROR_MATCHLIMIT occurred during a recursion, there was a memory
1689        leak if the size of the offset vector was greater than 30. When the vector
1690        is smaller, the saved offsets during recursion go onto a local stack
1691        vector, but for larger vectors malloc() is used. It was failing to free
1692        when the recursion yielded PCRE_ERROR_MATCH_LIMIT (or any other "abnormal"
1693        error, in fact).
1694    
1695    22. There was a missing #ifdef SUPPORT_UTF8 round one of the variables in the
1696        heapframe that is used only when UTF-8 support is enabled. This caused no
1697        problem, but was untidy.
1698    
1699    23. Steven Van Ingelgem's patch to CMakeLists.txt to change the name
1700        CMAKE_BINARY_DIR to PROJECT_BINARY_DIR so that it works when PCRE is
1701        included within another project.
1702    
1703    24. Steven Van Ingelgem's patches to add more options to the CMake support,
1704        slightly modified by me:
1705    
1706          (a) PCRE_BUILD_TESTS can be set OFF not to build the tests, including
1707              not building pcregrep.
1708    
1709          (b) PCRE_BUILD_PCREGREP can be see OFF not to build pcregrep, but only
1710              if PCRE_BUILD_TESTS is also set OFF, because the tests use pcregrep.
1711    
1712    25. Forward references, both numeric and by name, in patterns that made use of
1713        duplicate group numbers, could behave incorrectly or give incorrect errors,
1714        because when scanning forward to find the reference group, PCRE was not
1715        taking into account the duplicate group numbers. A pattern such as
1716        ^X(?3)(a)(?|(b)|(q))(Y) is an example.
1717    
1718    26. Changed a few more instances of "const unsigned char *" to USPTR, making
1719        the feature of a custom pointer more persuasive (as requested by a user).
1720    
1721    27. Wrapped the definitions of fileno and isatty for Windows, which appear in
1722        pcretest.c, inside #ifndefs, because it seems they are sometimes already
1723        pre-defined.
1724    
1725    28. Added support for (*UTF8) at the start of a pattern.
1726    
1727    29. Arrange for flags added by the "release type" setting in CMake to be shown
1728        in the configuration summary.
1729    
1730    
1731    Version 7.8 05-Sep-08
1732    ---------------------
1733    
1734    1.  Replaced UCP searching code with optimized version as implemented for Ad
1735        Muncher (http://www.admuncher.com/) by Peter Kankowski. This uses a two-
1736        stage table and inline lookup instead of a function, giving speed ups of 2
1737        to 5 times on some simple patterns that I tested. Permission was given to
1738        distribute the MultiStage2.py script that generates the tables (it's not in
1739        the tarball, but is in the Subversion repository).
1740    
1741    2.  Updated the Unicode datatables to Unicode 5.1.0. This adds yet more
1742        scripts.
1743    
1744    3.  Change 12 for 7.7 introduced a bug in pcre_study() when a pattern contained
1745        a group with a zero qualifier. The result of the study could be incorrect,
1746        or the function might crash, depending on the pattern.
1747    
1748    4.  Caseless matching was not working for non-ASCII characters in back
1749        references. For example, /(\x{de})\1/8i was not matching \x{de}\x{fe}.
1750        It now works when Unicode Property Support is available.
1751    
1752    5.  In pcretest, an escape such as \x{de} in the data was always generating
1753        a UTF-8 string, even in non-UTF-8 mode. Now it generates a single byte in
1754        non-UTF-8 mode. If the value is greater than 255, it gives a warning about
1755        truncation.
1756    
1757    6.  Minor bugfix in pcrecpp.cc (change "" == ... to NULL == ...).
1758    
1759    7.  Added two (int) casts to pcregrep when printing the difference of two
1760        pointers, in case they are 64-bit values.
1761    
1762    8.  Added comments about Mac OS X stack usage to the pcrestack man page and to
1763        test 2 if it fails.
1764    
1765    9.  Added PCRE_CALL_CONVENTION just before the names of all exported functions,
1766        and a #define of that name to empty if it is not externally set. This is to
1767        allow users of MSVC to set it if necessary.
1768    
1769    10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from
1770        the convenience functions in the pcre_get.c source file.
1771    
1772    11. An option change at the start of a pattern that had top-level alternatives
1773        could cause overwriting and/or a crash. This command provoked a crash in
1774        some environments:
1775    
1776          printf "/(?i)[\xc3\xa9\xc3\xbd]|[\xc3\xa9\xc3\xbdA]/8\n" | pcretest
1777    
1778        This potential security problem was recorded as CVE-2008-2371.
1779    
1780    12. For a pattern where the match had to start at the beginning or immediately
1781        after a newline (e.g /.*anything/ without the DOTALL flag), pcre_exec() and
1782        pcre_dfa_exec() could read past the end of the passed subject if there was
1783        no match. To help with detecting such bugs (e.g. with valgrind), I modified
1784        pcretest so that it places the subject at the end of its malloc-ed buffer.
1785    
1786    13. The change to pcretest in 12 above threw up a couple more cases when pcre_
1787        exec() might read past the end of the data buffer in UTF-8 mode.
1788    
1789    14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and
1790        the data contained the byte 0x85 as part of a UTF-8 character within its
1791        first line. This applied both to normal and DFA matching.
1792    
1793    15. Lazy qualifiers were not working in some cases in UTF-8 mode. For example,
1794        /^[^d]*?$/8 failed to match "abc".
1795    
1796    16. Added a missing copyright notice to pcrecpp_internal.h.
1797    
1798    17. Make it more clear in the documentation that values returned from
1799        pcre_exec() in ovector are byte offsets, not character counts.
1800    
1801    18. Tidied a few places to stop certain compilers from issuing warnings.
1802    
1803    19. Updated the Virtual Pascal + BCC files to compile the latest v7.7, as
1804        supplied by Stefan Weber. I made a further small update for 7.8 because
1805        there is a change of source arrangements: the pcre_searchfuncs.c module is
1806        replaced by pcre_ucd.c.
1807    
1808    
1809    Version 7.7 07-May-08
1810    ---------------------
1811    
1812    1.  Applied Craig's patch to sort out a long long problem: "If we can't convert
1813        a string to a long long, pretend we don't even have a long long." This is
1814        done by checking for the strtoq, strtoll, and _strtoi64 functions.
1815    
1816    2.  Applied Craig's patch to pcrecpp.cc to restore ABI compatibility with
1817        pre-7.6 versions, which defined a global no_arg variable instead of putting
1818        it in the RE class. (See also #8 below.)
1819    
1820    3.  Remove a line of dead code, identified by coverity and reported by Nuno
1821        Lopes.
1822    
1823    4.  Fixed two related pcregrep bugs involving -r with --include or --exclude:
1824    
1825        (1) The include/exclude patterns were being applied to the whole pathnames
1826            of files, instead of just to the final components.
1827    
1828        (2) If there was more than one level of directory, the subdirectories were
1829            skipped unless they satisfied the include/exclude conditions. This is
1830            inconsistent with GNU grep (and could even be seen as contrary to the
1831            pcregrep specification - which I improved to make it absolutely clear).
1832            The action now is always to scan all levels of directory, and just
1833            apply the include/exclude patterns to regular files.
1834    
1835    5.  Added the --include_dir and --exclude_dir patterns to pcregrep, and used
1836        --exclude_dir in the tests to avoid scanning .svn directories.
1837    
1838    6.  Applied Craig's patch to the QuoteMeta function so that it escapes the
1839        NUL character as backslash + 0 rather than backslash + NUL, because PCRE
1840        doesn't support NULs in patterns.
1841    
1842    7.  Added some missing "const"s to declarations of static tables in
1843        pcre_compile.c and pcre_dfa_exec.c.
1844    
1845    8.  Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was
1846        caused by fix #2  above. (Subsequently also a second patch to fix the
1847        first patch. And a third patch - this was a messy problem.)
1848    
1849    9.  Applied Craig's patch to remove the use of push_back().
1850    
1851    10. Applied Alan Lehotsky's patch to add REG_STARTEND support to the POSIX
1852        matching function regexec().
1853    
1854    11. Added support for the Oniguruma syntax \g<name>, \g<n>, \g'name', \g'n',
1855        which, however, unlike Perl's \g{...}, are subroutine calls, not back
1856        references. PCRE supports relative numbers with this syntax (I don't think
1857        Oniguruma does).
1858    
1859    12. Previously, a group with a zero repeat such as (...){0} was completely
1860        omitted from the compiled regex. However, this means that if the group
1861        was called as a subroutine from elsewhere in the pattern, things went wrong
1862        (an internal error was given). Such groups are now left in the compiled
1863        pattern, with a new opcode that causes them to be skipped at execution
1864        time.
1865    
1866    13. Added the PCRE_JAVASCRIPT_COMPAT option. This makes the following changes
1867        to the way PCRE behaves:
1868    
1869        (a) A lone ] character is dis-allowed (Perl treats it as data).
1870    
1871        (b) A back reference to an unmatched subpattern matches an empty string
1872            (Perl fails the current match path).
1873    
1874        (c) A data ] in a character class must be notated as \] because if the
1875            first data character in a class is ], it defines an empty class. (In
1876            Perl it is not possible to have an empty class.) The empty class []
1877            never matches; it forces failure and is equivalent to (*FAIL) or (?!).
1878            The negative empty class [^] matches any one character, independently
1879            of the DOTALL setting.
1880    
1881    14. A pattern such as /(?2)[]a()b](abc)/ which had a forward reference to a
1882        non-existent subpattern following a character class starting with ']' and
1883        containing () gave an internal compiling error instead of "reference to
1884        non-existent subpattern". Fortunately, when the pattern did exist, the
1885        compiled code was correct. (When scanning forwards to check for the
1886        existencd of the subpattern, it was treating the data ']' as terminating
1887        the class, so got the count wrong. When actually compiling, the reference
1888        was subsequently set up correctly.)
1889    
1890    15. The "always fail" assertion (?!) is optimzed to (*FAIL) by pcre_compile;
1891        it was being rejected as not supported by pcre_dfa_exec(), even though
1892        other assertions are supported. I have made pcre_dfa_exec() support
1893        (*FAIL).
1894    
1895    16. The implementation of 13c above involved the invention of a new opcode,
1896        OP_ALLANY, which is like OP_ANY but doesn't check the /s flag. Since /s
1897        cannot be changed at match time, I realized I could make a small
1898        improvement to matching performance by compiling OP_ALLANY instead of
1899        OP_ANY for "." when DOTALL was set, and then removing the runtime tests
1900        on the OP_ANY path.
1901    
1902    17. Compiling pcretest on Windows with readline support failed without the
1903        following two fixes: (1) Make the unistd.h include conditional on
1904        HAVE_UNISTD_H; (2) #define isatty and fileno as _isatty and _fileno.
1905    
1906    18. Changed CMakeLists.txt and cmake/FindReadline.cmake to arrange for the
1907        ncurses library to be included for pcretest when ReadLine support is
1908        requested, but also to allow for it to be overridden. This patch came from
1909        Daniel Bergström.
1910    
1911    19. There was a typo in the file ucpinternal.h where f0_rangeflag was defined
1912        as 0x00f00000 instead of 0x00800000. Luckily, this would not have caused
1913        any errors with the current Unicode tables. Thanks to Peter Kankowski for
1914        spotting this.
1915    
1916    
1917    Version 7.6 28-Jan-08
1918    ---------------------
1919    
1920    1.  A character class containing a very large number of characters with
1921        codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer
1922        overflow.
1923    
1924    2.  Patch to cut out the "long long" test in pcrecpp_unittest when
1925        HAVE_LONG_LONG is not defined.
1926    
1927    3.  Applied Christian Ehrlicher's patch to update the CMake build files to
1928        bring them up to date and include new features. This patch includes:
1929    
1930        - Fixed PH's badly added libz and libbz2 support.
1931        - Fixed a problem with static linking.
1932        - Added pcredemo. [But later removed - see 7 below.]
1933        - Fixed dftables problem and added an option.
1934        - Added a number of HAVE_XXX tests, including HAVE_WINDOWS_H and
1935            HAVE_LONG_LONG.
1936        - Added readline support for pcretest.
1937        - Added an listing of the option settings after cmake has run.
1938    
1939    4.  A user submitted a patch to Makefile that makes it easy to create
1940        "pcre.dll" under mingw when using Configure/Make. I added stuff to
1941        Makefile.am that cause it to include this special target, without
1942        affecting anything else. Note that the same mingw target plus all
1943        the other distribution libraries and programs are now supported
1944        when configuring with CMake (see 6 below) instead of with
1945        Configure/Make.
1946    
1947    5.  Applied Craig's patch that moves no_arg into the RE class in the C++ code.
1948        This is an attempt to solve the reported problem "pcrecpp::no_arg is not
1949        exported in the Windows port". It has not yet been confirmed that the patch
1950        solves the problem, but it does no harm.
1951    
1952    6.  Applied Sheri's patch to CMakeLists.txt to add NON_STANDARD_LIB_PREFIX and
1953        NON_STANDARD_LIB_SUFFIX for dll names built with mingw when configured
1954        with CMake, and also correct the comment about stack recursion.
1955    
1956    7.  Remove the automatic building of pcredemo from the ./configure system and
1957        from CMakeLists.txt. The whole idea of pcredemo.c is that it is an example
1958        of a program that users should build themselves after PCRE is installed, so
1959        building it automatically is not really right. What is more, it gave
1960        trouble in some build environments.
1961    
1962    8.  Further tidies to CMakeLists.txt from Sheri and Christian.
1963    
1964    
1965    Version 7.5 10-Jan-08
1966  ---------------------  ---------------------
1967    
1968  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'
1969      values in parens when parsing an RE using the C++ wrapper."      values in parens when parsing an RE using the C++ wrapper."
1970    
1971  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.
1972      Characters greater than 255 were excluded from the class instead of being      Characters greater than 255 were excluded from the class instead of being
1973      included.      included.
1974    
1975  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
1976      [:^space:].      [:^space:].
1977    
1978  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
1979      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
1980      I have changed it.      I have changed it.
1981    
1982  5.  The construct (?&) was not diagnosed as a syntax error (it referenced the  5.  The construct (?&) was not diagnosed as a syntax error (it referenced the
1983      first named subpattern) and a construct such as (?&a) would reference the      first named subpattern) and a construct such as (?&a) would reference the
1984      first named subpattern whose name started with "a" (in other words, the      first named subpattern whose name started with "a" (in other words, the
1985      length check was missing). Both these problems are fixed. "Subpattern name      length check was missing). Both these problems are fixed. "Subpattern name
1986      expected" is now given for (?&) (a zero-length name), and this patch also      expected" is now given for (?&) (a zero-length name), and this patch also
1987      makes it give the same error for \k'' (previously it complained that that      makes it give the same error for \k'' (previously it complained that that
1988      was a reference to a non-existent subpattern).      was a reference to a non-existent subpattern).
1989    
1990  6.  The erroneous patterns (?+-a) and (?-+a) give different error messages;  6.  The erroneous patterns (?+-a) and (?-+a) give different error messages;
1991      this is right because (?- can be followed by option settings as well as by      this is right because (?- can be followed by option settings as well as by
1992      digits. I have, however, made the messages clearer.      digits. I have, however, made the messages clearer.
1993    
1994  7.  Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns  7.  Patterns such as (?(1)a|b) (a pattern that contains fewer subpatterns
1995      than the number used in the conditional) now cause a compile-time error.      than the number used in the conditional) now cause a compile-time error.
1996      This is actually not compatible with Perl, which accepts such patterns, but      This is actually not compatible with Perl, which accepts such patterns, but
1997      treats the conditional as always being FALSE (as PCRE used to), but it      treats the conditional as always being FALSE (as PCRE used to), but it
1998      seems to me that giving a diagnostic is better.      seems to me that giving a diagnostic is better.
1999    
2000  8.  Change "alphameric" to the more common word "alphanumeric" in comments  8.  Change "alphameric" to the more common word "alphanumeric" in comments
2001      and messages.      and messages.
2002    
2003  9.  Fix two occurrences of "backslash" in comments that should have been  9.  Fix two occurrences of "backslash" in comments that should have been
2004      "backspace".      "backspace".
2005    
2006    10. Remove two redundant lines of code that can never be obeyed (their function
2007        was moved elsewhere).
2008    
2009    11. The program that makes PCRE's Unicode character property table had a bug
2010        which caused it to generate incorrect table entries for sequences of
2011        characters that have the same character type, but are in different scripts.
2012        It amalgamated them into a single range, with the script of the first of
2013        them. In other words, some characters were in the wrong script. There were
2014        thirteen such cases, affecting characters in the following ranges:
2015    
2016          U+002b0 - U+002c1
2017          U+0060c - U+0060d
2018          U+0061e - U+00612
2019          U+0064b - U+0065e
2020          U+0074d - U+0076d
2021          U+01800 - U+01805
2022          U+01d00 - U+01d77
2023          U+01d9b - U+01dbf
2024          U+0200b - U+0200f
2025          U+030fc - U+030fe
2026          U+03260 - U+0327f
2027          U+0fb46 - U+0fbb1
2028          U+10450 - U+1049d
2029    
2030    12. The -o option (show only the matching part of a line) for pcregrep was not
2031        compatible with GNU grep in that, if there was more than one match in a
2032        line, it showed only the first of them. It now behaves in the same way as
2033        GNU grep.
2034    
2035    13. If the -o and -v options were combined for pcregrep, it printed a blank
2036        line for every non-matching line. GNU grep prints nothing, and pcregrep now
2037        does the same. The return code can be used to tell if there were any
2038        non-matching lines.
2039    
2040    14. Added --file-offsets and --line-offsets to pcregrep.
2041    
2042    15. The pattern (?=something)(?R) was not being diagnosed as a potentially
2043        infinitely looping recursion. The bug was that positive lookaheads were not
2044        being skipped when checking for a possible empty match (negative lookaheads
2045        and both kinds of lookbehind were skipped).
2046    
2047    16. Fixed two typos in the Windows-only code in pcregrep.c, and moved the
2048        inclusion of <windows.h> to before rather than after the definition of
2049        INVALID_FILE_ATTRIBUTES (patch from David Byron).
2050    
2051    17. Specifying a possessive quantifier with a specific limit for a Unicode
2052        character property caused pcre_compile() to compile bad code, which led at
2053        runtime to PCRE_ERROR_INTERNAL (-14). Examples of patterns that caused this
2054        are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that
2055        caused the error; without that there was no problem.
2056    
2057    18. Added --enable-pcregrep-libz and --enable-pcregrep-libbz2.
2058    
2059    19. Added --enable-pcretest-libreadline.
2060    
2061    20. In pcrecpp.cc, the variable 'count' was incremented twice in
2062        RE::GlobalReplace(). As a result, the number of replacements returned was
2063        double what it should be. I removed one of the increments, but Craig sent a
2064        later patch that removed the other one (the right fix) and added unit tests
2065        that check the return values (which was not done before).
2066    
2067    21. Several CMake things:
2068    
2069        (1) Arranged that, when cmake is used on Unix, the libraries end up with
2070            the names libpcre and libpcreposix, not just pcre and pcreposix.
2071    
2072        (2) The above change means that pcretest and pcregrep are now correctly
2073            linked with the newly-built libraries, not previously installed ones.
2074    
2075        (3) Added PCRE_SUPPORT_LIBREADLINE, PCRE_SUPPORT_LIBZ, PCRE_SUPPORT_LIBBZ2.
2076    
2077    22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.*
2078        crashed when matching a string such as a\x{2029}b (note that \x{2029} is a
2079        UTF-8 newline character). The key issue is that the pattern starts .*;
2080        this means that the match must be either at the beginning, or after a
2081        newline. The bug was in the code for advancing after a failed match and
2082        checking that the new position followed a newline. It was not taking
2083        account of UTF-8 characters correctly.
2084    
2085    23. PCRE was behaving differently from Perl in the way it recognized POSIX
2086        character classes. PCRE was not treating the sequence [:...:] as a
2087        character class unless the ... were all letters. Perl, however, seems to
2088        allow any characters between [: and :], though of course it rejects as
2089        unknown any "names" that contain non-letters, because all the known class
2090        names consist only of letters. Thus, Perl gives an error for [[:1234:]],
2091        for example, whereas PCRE did not - it did not recognize a POSIX character
2092        class. This seemed a bit dangerous, so the code has been changed to be
2093        closer to Perl. The behaviour is not identical to Perl, because PCRE will
2094        diagnose an unknown class for, for example, [[:l\ower:]] where Perl will
2095        treat it as [[:lower:]]. However, PCRE does now give "unknown" errors where
2096        Perl does, and where it didn't before.
2097    
2098    24. Rewrite so as to remove the single use of %n from pcregrep because in some
2099        Windows environments %n is disabled by default.
2100    
2101    
2102  Version 7.4 21-Sep-07  Version 7.4 21-Sep-07

Legend:
Removed from v.275  
changed lines
  Added in v.1306

  ViewVC Help
Powered by ViewVC 1.1.5