Lines Matching full:was
14 detected error. This bug was discovered by the LLVM fuzzer.
19 This bug was discovered by the LLVM fuzzer.
21 3. A repeated conditional group whose condition was a reference by name caused
22 a buffer overflow if there was more than one group with the given name.
23 This bug was discovered by the LLVM fuzzer.
27 /(?J)(?'d'(?'d'\g{d}))/. This bug was discovered by the LLVM fuzzer.
31 a buffer overflow at compile time. This bug was discovered by the LLVM
35 provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
43 8. There was no check for integer overflow in subroutine calls such as (?123).
45 9. The table entry for \l in EBCDIC environments was incorrect, leading to its
48 10. There was a buffer overflow if pcre_exec() was called with an ovector of
49 size 1. This bug was found by american fuzzy lop.
52 an empty string was repeated, it was not identified as matching an empty
55 12. In an EBCDIC environment, pcretest was mishandling the escape sequences
58 13. In an EBCDIC environment, \a in a pattern was converted to the ASCII
68 16. When PCRE was compiled without UCP support, the use of \p and \P gave an
72 17. \h within a class was incorrectly compiled in EBCDIC environments.
82 for example, /(?(R))*+/, was incorrectly compiled.
98 25. If (?R was followed by - or + incorrect behaviour happened instead of a
110 28. If pcregrep was given the -q option with -c or -l, or when handling a
114 control verbs. This issue was found by Karl Skomski with a custom LLVM
121 (?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
130 This issue was found by Karl Skomski with a custom LLVM fuzzer.
133 repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
135 35. Match limit check added to JIT recursion. This issue was found by Karl
148 39. An incorrect error "overran compiling workspace" was given if there were
151 workspace. The test for overflow was not including the safety margin.
153 40. A match limit issue is fixed in JIT which was found by Karl Skomski
161 escape was being ignored.
166 by a single ASCII character in a class item, was incorrectly compiled in
170 45. [:punct:] in UCP mode was matching some characters in the range 128-255
175 When a Unicode property was also in the class (if PCRE_UCP is set, escapes
185 However, it was failing to mark any other groups between the hightest
187 those groups contained whatever was previously there. An example is the
190 2. If an assertion condition was quantified with a minimum of zero (an odd
201 that had to be saved was greater than ten.
214 /^(?:(a)|b)(?(1)A|B)/, is another kind of back reference, but it was not
216 was called with an ovector that was too small to hold the capture, and there
217 was no other kind of back reference (a situation which is probably quite
218 rare). The effect of the bug was that the condition was always treated as
224 PCRE_DUPNAMES was not set caused the amount of memory needed for the pattern
232 11. If an assertion that was used as a condition was quantified with a minimum
234 unlimited repetition and could match an empty string, a segfault was
241 failed to allow the zero-repeat case if pcre2_exec() was called with an
251 was combined with setting a null ovector, for example \O\C+ as a subject
259 memory address was read. This bug was reported as "heap overflow",
265 incorrect code to be compiled. This bug was reported as "heap overflow",
277 mode. In that example, the range a-j was left out of the class.
282 27. The pattern /(?(?!)^)/ caused references to random memory. This bug was
285 28. The assertion (?!) is optimized to (*FAIL). This was not handled correctly
286 when this assertion was used as a condition, for example (?(?!)a|b). In
297 because \S ensures they are all in the class. The code for doing this was
299 compile the pattern, leading to a buffer overflow. This bug was discovered
303 other kinds of group caused stack overflow at compile time. This bug was
307 between a subroutine call and its quantifier was incorrectly compiled,
308 leading to buffer overflow or other errors. This bug was discovered by the
311 33. The illegal pattern /(?(?<E>.*!.*)?)/ was not being diagnosed as missing an
312 assertion after (?(. The code was failing to check the character after
314 was discovered by the LLVM fuzzer.
317 a fixed maximum following a group that contains a subroutine reference was
318 incorrectly compiled and could trigger buffer overflow. This bug was
323 lookbehind assertion. This bug was discovered by the LLVM fuzzer.
328 37. There was a similar problem to 36 in pcretest for global matches.
330 38. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*),
334 other cases where backtracking after \C could crash. This set of bugs was
338 a very long time if mutual recursion was present many times in a pattern,
340 method has been implemented. This infelicity was discovered by the LLVM
343 40. Static linking against the PCRE library using the pkg-config module was
380 the interpreter was reporting a match of 'NON QUOTED ' only, whereas the
382 for an empty string was breaking the inner loop and carrying on at a lower
387 8. Fixed a bug that was incorrectly auto-possessifying \w+ in the pattern
404 the reference to 'Name' was incorrectly treated as a reference to a
408 one "other case" was incorrectly compiled such that it would only try to
411 13. When a pattern starting with \s was studied, VT was not included in the
416 was incorrectly terminated at the ].
419 than one "other case" was studied, PCRE did not set up the starting code
431 19. Incorrect code was compiled if a group that contained an internal recursive
432 back reference was optional (had quantifier with a minimum of zero). This
439 This was not the same bug as 19 above.
460 of a match later then the end of the match. The pcretest program was not
461 handling the case sensibly - it was outputting from the start to the next
500 than one alternative case was not the first character of a range, not all
502 are both alternative cases for S: the class [RST] was handled correctly,
503 but [R-T] was not.
505 13. The configure.ac file always checked for pthread support when JIT was
507 check for the presence of windows.h (which was already tested for).
520 this should make the test pass on some versions of Solaris where it was
525 16. If --with-pcregrep-bufsize was given a non-integer value such as "50K",
526 there was a message during ./configure, but it did not stop. This now
531 17. If --enable-bsr-anycrlf was set, the special 16/32-bit test failed. This
532 was a bug in the test system, which is now fixed. Also, the list of various
536 18. pcretest was missing "-C bsr" for displaying the \R default setting.
554 23. When UTF was disabled, the JIT program reported some incorrect compile
575 enable coverage support, which is totally false. There was also support for
584 these cases). There was also one in pcretest.c.
590 breaking an infinite loop) was broken when the group contained a repeated
593 UTF-8 mode). The effect was undefined: the group might or might not be
596 7. The code for checking whether a group could match an empty string was not
612 there was no match, the code could incorrectly back up beyond the match
618 item was recorded. For example, the pattern (?(?=ab)ab) recorded "a" as a
642 first one was inspected. This change makes PCRE more compatible with Perl.
685 24. RunTest used to grumble if an inappropriate test was selected explicitly,
687 of tests when one of them was inappropriate. Now it just skips any
692 data that they returned was rubbish.
694 26. In UCP mode, \s was not matching two of the characters that Perl matches,
707 (because it's meaningless), this was not happening when PCRE_CASELESS was
732 However, this was not working for (?!) because it is optimized to (*FAIL),
745 group such as (a\Kb)*+ was not working.
766 non-UTF 16-bit or 32-bit modes caused an internal error when PCRE was
813 (b) Minimum length was not checked before the matching is started.
815 11. The value of capture_last that is passed to callouts was incorrect in some
816 cases when there was a capture on one path that was subsequently abandoned
857 22. When a pattern was compiled with automatic callouts (PCRE_AUTO_CALLOUT) and
858 there was a conditional group that depended on an assertion, if the
859 assertion was false, the callout that immediately followed the alternation
860 in the condition was skipped when pcre_exec() was used for matching.
866 24. In 8.31, (*COMMIT) was confined to within a recursive subpattern. Perl also
911 37. The value of the max lookbehind was not correctly preserved if a compiled
912 and saved regex was reloaded on a host of different endianness.
916 because it was almost full.
957 of a line, was being set incorrectly in cases where .* appeared inside
958 atomic brackets at the start of a pattern, or where there was a subsequent
1006 general tidy up of EBCDIC-related issues, and the documentation was also
1077 29. If pcre_exec() or pcre_dfa_exec() was called with a negative value for
1078 the subject string length, the error given was PCRE_ERROR_BADOFFSET, which
1079 was confusing. There is now a new error PCRE_ERROR_BADLENGTH for this case.
1112 to unsigned type, result still unsigned" that was given by an MS compiler
1120 (a) /^(..)\1/ did not partially match "aba" because checking references was
1124 (b) \R did not give a hard partial match if \r was found at the end of the
1130 (d) When newline was set to CRLF, a pattern such as /a$/ did not recognize
1133 (e) When newline was set to CRLF, the metacharacter "." did not recognize
1186 matches in certain environments (the workspace was not being correctly
1190 25. \s*\R was auto-possessifying the \s* when it should not, whereas \S*\R
1191 was not doing so when it should - probably a typo introduced by SVN 528
1194 26. When PCRE_UCP was not set, \w+\x{c4} was incorrectly auto-possessifying the
1195 \w+ when the character tables indicated that \x{c4} was a word character.
1202 there were back references that the ovector was too small to contain
1204 highest capturing number was not used, memory off the end of the ovector
1205 was incorrectly being set to -1. (It was using the size of the temporary
1223 34. Fixed typos in pcregrep: in two places there was SUPPORT_LIBZ2 instead of
1225 was enabled.
1229 36. When /((?:a?)*)*c/ or /((?>a?)*)*c/ was matched against "aac", it set group
1240 39. If PCRE was compiled with UTF support, in three places in the DFA
1241 matcher there was code that should only have been obeyed in UTF mode, but
1242 was being obeyed unconditionally. In 8-bit mode this could cause incorrect
1267 since it was replaced by pcre_fullinfo() in February 2000.
1269 4. For a non-anchored pattern, if (*SKIP) was given with a name that did not
1272 was introduced by fix 17 of release 8.21.
1274 5. A reference to an unset group with zero minimum repetition was giving
1276 /(another)?(\1?)test/ matched against "hello world test". This bug was
1282 7. RunGrepTest failed on msys because \r\n was replaced by whitespace when the
1283 command "pattern=`printf 'xxx\r\njkl'`" was run. The pattern is now taken
1331 was introduced by change 18 for 8.20.
1337 erroneously being rejected as "not fixed length" if PCRE_CASELESS was set.
1338 This bug was probably introduced by change 9 of 8.13.
1350 8. A possessively repeated conditional subpattern such as (?(?=c)c|d)++ was
1354 one behaved incorrectly. For example, (A){2,}+ behaved as if it was
1371 15. If a forward reference was repeated with an upper limit of around 2000,
1373 maximum number of forward references (including repeats) was limited by the
1380 16. A repeated forward reference in a pattern such as (a)(?2){2}(.) was
1384 in the match, the SKIP should be ignored. This was not happening; instead
1385 the SKIP was being treated as NOMATCH. For patterns such as
1386 /A(*MARK:A)A+(*SKIP:B)Z|AAC/ this meant that the AAC branch was never
1400 19. If the /S+ option was used in pcretest to study a pattern using JIT,
1416 25. The CheckMan script was not being included in the distribution. Also, added
1420 26. If study data was being save in a file and studying had not found a set of
1422 never used) was taken from uninitialized memory and so caused valgrind to
1429 29. Computation of memory usage for the table of capturing group names was
1445 pcre_exec() was not big enough for this capture, the yield of the function
1446 was still zero ("insufficient space for captured substrings"). This cannot
1455 matching, and copies in the captures as far as possible afterwards. It was
1467 ovector, the return from the function was zero, implying that there were
1471 6. If a subpattern that was called recursively or as a subroutine contained
1476 7. If a pattern such as /a(*SKIP)c|b(*ACCEPT)|/ was studied, it stopped
1483 8. If (*THEN) was present in the first (true) branch of a conditional group,
1484 it was not handled as intended. [But see 16 below.]
1489 10. A pathological pattern such as /(*ACCEPT)a/ was miscompiled, thinking that
1505 14. If (*THEN) appeared in a group that was called recursively or as a
1511 was behaving differently to Perl. PCRE backtracked into A, but Perl goes to
1513 characters to be part of a surrounding alternative, whereas PCRE was
1532 19. If the PCRE_NO_START_OPTIMIZE option was set for pcre_compile(), it did not
1533 suppress the check for a minimum subject length at run time. (If it was
1543 was an instance in pcretest which caused it to go wrong when processing
1583 8. When \R was used with a maximizing quantifier it failed to skip backwards
1593 time (the PCRE_DOTALL option was changed this way some time ago: version
1595 which was always a bit of a fudge. It also means that there is one less
1607 (?<=(a)+) was not diagnosed as invalid (non-fixed-length lookbehind).
1610 (^a|^)+ was not marked as anchored.
1611 (.*a|.*)+ was not marked as matching at start or after a newline.
1631 15. When (*ACCEPT) was used in a subpattern that was called recursively, the
1632 restoration of the capturing data to the outer values was not happening
1636 empty string, and PCRE_NOTEMPTY was set, pcre_exec() thought the whole
1640 17. There was optimizing code for the last branch of non-capturing parentheses,
1647 18. If a pattern containing \R was studied, it was assumed that \R always
1651 19. If a pattern containing (*ACCEPT) was studied, the minimum subject length
1652 was incorrectly computed.
1659 21. When (*ACCEPT) was used in an assertion that matched an empty string and
1660 PCRE_NOTEMPTY was set, PCRE applied the non-empty test to the assertion.
1662 22. When an atomic group that contained a capturing parenthesis was
1664 capturing was not being forgotten if a higher numbered group was later
1684 (?(?=(a))a) was matched against "a", no capturing was returned.
1687 the code for finding the minimum length of a possible match was handling
1698 first character it looked at was a mark character.
1707 31. If \k was not followed by a braced, angle-bracketed, or quoted name, PCRE
1714 33. If --only-matching or --colour was set on a pcregrep call whose pattern
1716 was done as if at the line start. Thus, for example, /^01|^02/ incorrectly
1728 36. \g was being checked for fancy things in a character class, when it should
1731 37. PCRE was rejecting [:a[:digit:]] whereas Perl was not. It seems that the
1738 38. PCRE was giving an error for \N with a braced quantifier such as {1,} (this
1739 was because it thought it was \N{name}, which is not supported).
1751 happen only once. PCRE was, however incorrectly giving a compile time error
1786 partial match of an empty string instead of no match. This was specific to
1790 complete match instead of a partial match. This bug was dependent on both
1793 48. For a pattern such as /\babc|\bdef/ pcre_study() was failing to set up the
1794 starting byte set, because \b was not being ignored.
1808 3. If the --colour option was given to pcregrep with -v (invert match), it
1813 4. Another pcregrep bug caused similar problems if --colour was specified with
1816 5. In pcregrep, when a pattern that ended with a literal newline sequence was
1817 matched in multiline mode, the following line was shown as part of the
1820 6. Another pcregrep bug in multiline mode, when --colour was specified, caused
1822 to overrun the end of the current line. If another match was found, it was
1825 7. If pcregrep was compiled under Windows, there was a reference to the
1826 function pcregrep_exit() before it was defined. I am assuming this was
1827 the cause of the "error C2371: 'pcregrep_exit' : redefinition;" that was
1834 1. (*THEN) was not working properly if there were untried alternatives prior
1841 2. (*COMMIT) was not overriding (*THEN), as it does in Perl. In a pattern
1849 in [\x00-\xff\s]. (This was a bug related to the fact that VT is not part
1854 an empty string was starting at the "start of match" point. This has been
1867 match rather than a full match, which was wrong by the old rules, but is
1870 6. There was a bug in the handling of #-introduced comments, recognized when
1873 UTF-8 encoding is 0xd1,0x85), this was misinterpreted as a newline when
1875 but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several
1878 7. Related to (6) above, when pcre_compile() was skipping #-introduced
1880 the only newline sequence it recognized was NL. It now handles newlines
1891 11. When the -o option was used, pcregrep was setting a return code of 1, even
1892 when matches were found, and --line-buffered was not being honoured.
1901 (a) When the newline convention was "crlf", pcretest got it wrong, skipping
1908 than one byte was nonsense.)
1913 14. Neither pcre_exec() nor pcre_dfa_exec() was checking that the value given
1914 as a starting offset was within the subject string. There is now a new
1920 starting offset points to the beginning of a UTF-8 character was
1926 17. Nobody had reported that the --include_dir option, which was added in
1939 19. If \c was followed by a multibyte UTF-8 character, bad things happened. A
1954 memory required was incorrectly computed, leading to "Failed: internal
1967 2. (*ACCEPT) was not working when inside an atomic group.
1999 11. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was
2001 127 whose first byte was different to the first byte of the other case of
2002 the letter, the other case of this starting letter was not recognized
2005 12. If a pattern that was studied started with a repeated Unicode property
2006 test, for example, \p{Nd}+, there was the theoretical possibility of
2008 not have actually happened in practice until change 8 above was made (it
2018 15. If a repeated Unicode property match (e.g. \p{Lu}*) was used with non-UTF-8
2030 the end, a newline was missing in the output.
2038 caused a problem in UTF-8 mode when pcre_study() was used to create a list
2039 of bytes that can start a match. For \s, it was including 0x85 and 0xa0,
2068 inttypes.h instead. This fixes a bug that was introduced by change 8.01/8.
2090 counting zeros. There was no check for running off the end of the string,
2091 which could happen if a new error number was added without updating the
2096 11. \K was not working if it appeared in an atomic group or in a group that
2097 was called as a "subroutine", or in an assertion. Perl 5.11 documents that
2109 second branch in the above example - was incorrectly given the compile-
2111 was not correctly checking the subroutine for matching a non-empty string.
2132 the reset was to the original external option setting. (An optimization
2133 abstracts leading options settings into an external setting, which was the
2138 assertion pattern did not match (meaning that the assertion was true), it
2139 was incorrectly treated as false if the SKIP had been reached during the
2142 4. If an item that is not supported by pcre_dfa_exec() was encountered in an
2147 5. The C++ GlobalReplace function was not working like Perl for the special
2209 14. Change 8.00/11 was not quite complete: code had been accidentally omitted,
2211 in a UTF-8 pattern where \W was quantified with a minimum of 3.
2217 unsigned char *" (and uschar is typedeffed as "unsigned char"), it was
2236 refers, was giving matches when it shouldn't. For example, xa=xaaa would
2253 was out-of-date, and there was no check on the pcre_compile() error code
2262 zero, as does GNU grep. However, pcregrep was also printing all files when
2263 --files-with-matches was added. Now, when both options are given, it prints
2269 4. The long form of the pcregrep -F option was incorrectly implemented as
2271 but it seems right to fix it, and I didn't think it was worth preserving
2279 6. No libpcreposix.pc file was created for pkg-config; there was just
2289 8. A pattern such as /\x{123}{2,2}+/8 was incorrectly compiled; the trigger
2290 was a minimum greater than 1 for a wide character in a possessive
2309 used to be given if ever the end of the subject was reached; now it is
2310 given only if matching could not proceed because another character was
2317 if the pattern had a "must contain" character that was already found in the
2318 earlier partial match, unless partial matching was again requested. For
2320 "g". If the first part-match was for the string "dog", restarting with
2356 [The bug was that it was starting one character too far in when skipping
2365 21. If the maximum number of capturing subpatterns in a recursion was greater
2366 than the maximum at the outer level, the higher number was returned, but
2383 length of subject string that was needed in order to match a given pattern.
2384 (It was back references and recursion that I had previously got hung up
2394 Oops. What is worse, even when it was passed study data, there was a bug in
2423 2. The "typedef int BOOL" in pcre_internal.h that was included inside the
2428 3. The pcre_config() function was treating the PCRE_MATCH_LIMIT and
2436 5. In pcregrep, when --colour was used with -o, the list of matching strings
2437 was not coloured; this is different to GNU grep, so I have changed it to be
2440 6. When --colo(u)r was used in pcregrep, only the first matching substring in
2441 each matching line was coloured. Now it goes on to look for further matches
2450 8. The pattern (?(?=.*b)b|^) was incorrectly compiled as "match must be at
2451 start or after a newline", because the conditional assertion was not being
2455 9. If auto-callout was enabled in a pattern with a conditional group whose
2456 condition was an assertion, PCRE could crash during matching, both with
2459 10. The PCRE_DOLLAR_ENDONLY option was not working when pcre_dfa_exec() was
2462 11. Unicode property support in character classes was not working for
2483 19. A conditional group that had only one branch was not being correctly
2490 20. If a pattern that was compiled with callouts was matched using pcre_dfa_
2493 21. If PCRE_ERROR_MATCHLIMIT occurred during a recursion, there was a memory
2494 leak if the size of the offset vector was greater than 30. When the vector
2496 vector, but for larger vectors malloc() is used. It was failing to free
2500 22. There was a missing #ifdef SUPPORT_UTF8 round one of the variables in the
2502 problem, but was untidy.
2519 because when scanning forward to find the reference group, PCRE was not
2542 to 5 times on some simple patterns that I tested. Permission was given to
2553 4. Caseless matching was not working for non-ASCII characters in back
2554 references. For example, /(\x{de})\1/8i was not matching \x{de}\x{fe}.
2557 5. In pcretest, an escape such as \x{de} in the data was always generating
2574 10. The PCRE_EXP_DEFN macro which precedes exported functions was missing from
2583 This potential security problem was recorded as CVE-2008-2371.
2587 pcre_dfa_exec() could read past the end of the passed subject if there was
2594 14. A similar bug to 7.3/2 existed when the PCRE_FIRSTLINE option was set and
2633 (2) If there was more than one level of directory, the subdirectories were
2650 8. Applied Craig's patch to pcrecpp.cc to fix a problem in OS X that was
2652 first patch. And a third patch - this was a messy problem.)
2664 12. Previously, a group with a zero repeat such as (...){0} was completely
2666 was called as a subroutine from elsewhere in the pattern, things went wrong
2667 (an internal error was given). Such groups are now left in the compiled
2690 compiled code was correct. (When scanning forwards to check for the
2691 existence of the subpattern, it was treating the data ']' as terminating
2693 was subsequently set up correctly.)
2696 it was being rejected as not supported by pcre_dfa_exec(), even though
2704 OP_ANY for "." when DOTALL was set, and then removing the runtime tests
2716 19. There was a typo in the file ucpinternal.h where f0_rangeflag was defined
2783 4. PCRECPP_STATIC was referenced in pcrecpp_internal.h, but nowhere was it
2787 5. The construct (?&) was not diagnosed as a syntax error (it referenced the
2790 length check was missing). Both these problems are fixed. "Subpattern name
2793 was a reference to a non-existent subpattern).
2812 was moved elsewhere).
2835 12. The -o option (show only the matching part of a line) for pcregrep was not
2836 compatible with GNU grep in that, if there was more than one match in a
2847 15. The pattern (?=something)(?R) was not being diagnosed as a potentially
2848 infinitely looping recursion. The bug was that positive lookaheads were not
2859 are: /\p{Zl}{2,3}+/8 and /\p{Cc}{2}+/8. It was the possessive "+" that
2860 caused the error; without that there was no problem.
2866 20. In pcrecpp.cc, the variable 'count' was incremented twice in
2867 RE::GlobalReplace(). As a result, the number of replacements returned was
2870 that check the return values (which was not done before).
2886 newline. The bug was in the code for advancing after a failed match and
2887 checking that the new position followed a newline. It was not taking
2890 23. PCRE was behaving differently from Perl in the way it recognized POSIX
2891 character classes. PCRE was not treating the sequence [:...:] as a
2910 1. Change 7.3/28 was implemented for classes by looking at the bitmap. This
2912 LF". That isn't really right - the whole point of the change was to try to
2913 help when there was an actual mention of one of the two characters. So now
2917 2. The 32-bit options word was also used for 6 internal flags, but the numbers
2919 Fortunately, there was spare space in the data structure, and so I have
2926 facility is supposed to tell if (?J) was ever used, so now (?J) at the
2932 5. doc/pcresyntax.html was missing from the distribution.
2939 windows.h file is present (where different names are used). [This was
2945 9. When pcregrep was used with the --colour option, it missed the line ending
2948 10. It was pointed out to me that arrays of string pointers cause lots of
2963 unicode-properties was also set.
2986 line "#include <pcre.h>" was included in pcre_internal.h. The use of angle
2993 I have a vague recollection that the change was concerned with compiling in
2999 character was \x{1ec5}). *Character* 0x85 is one of the "any" newline
3001 of another character. The bug was that, for an unlimited repeat of . in
3002 not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by
3013 6. ESC_K was left out of the EBCDIC table.
3025 checking that an empty string has been matched. Previously this was taken
3030 syntax that is required for Windows, and which was going wrong for the
3032 problem was solved for the main library.
3036 limits. As the maximum quantifier is 65535, the maximum group length was
3059 string has been matched (to stop an infinite loop). It was not recognizing
3061 subpattern was within another subpattern. For example, it looped when
3062 trying to match (((?(1)X|))*) but it was OK with ((?(1)X|)*) where the
3063 condition was not nested. This bug has been fixed.
3105 behind). There were bugs in these functions when a repeated \p or \P was
3110 (a) A item such as \p{Yi}{3} in a lookbehind was not treated as fixed
3159 was not 2, because the output contained actual offsets. The recent new
3196 terminating or by crashing. Diagnosed by Viktor Griph; it was in the code
3200 hundred) was running out of internal workspace during the pre-compile
3215 12. If \p or \P was used in non-UTF-8 mode on a character greater than 127
3230 was different. A call to "sort" has been inserted into RunGrepTest for the
3249 Weber: (1) pcre_internal.h was missing some function renames; (2) updated
3255 copy. The trailing space was an accident, so I've just removed it.
3280 (a) It was defining its arguments as char * instead of void *.
3282 (b) It was assuming that all moves were upwards in memory; this was true
3305 (b) When PCRE was configured to use the heap rather than the stack for
3306 recursion during matching, it was not correctly preserving the data for
3325 there was also a test in test 3 (the locale tests) that used /B and
3331 14. If erroroffset was passed as NULL to pcre_compile, it provoked a
3334 15. In multiline mode when the newline sequence was set to "any", the pattern
3348 19. In pcretest, if the pattern /(?m)^$/g<any> was matched against the string
3350 was because its rules for how to advance for /g after matching an empty
3355 extending its buffers when necessary. It was getting this wrong when the
3396 length. The relevant options are -x, and -i in UTF-8 mode. The result was
3397 that the computed length was too small. The symptoms of this bug were
3417 6. The escape sequence \n was being treated as whatever was defined as
3418 "newline". Not only was this contrary to the documentation, which states
3420 "newline" was defined as CRLF. This has been fixed.
3423 was being set to -1 for the "end of line" case (supposedly a value that no
3428 8. In pcre_version.c, the version string was being built by a sequence of
3432 compiler treats it as an empty string (which was what was wanted) but it is
3441 10. Originally, pcretest opened its input and output without "b"; then I was
3442 told that "b" was needed in some environments, so it was added for release
3444 systems.) Later I was told that it is wrong for the input on Windows. I've
3459 scripts are not C programs :-) and which was not noticed because it works
3464 necessary. This feature was broken for very long pattern lines, leading to
3465 a string of junk being passed to pcre_compile() if the pattern was longer
3469 amount of memory needed for a compiled pattern. Previously, there was code
3470 that made a preliminary scan of the pattern in order to do this. That was
3471 OK when PCRE was new, but as the facilities have expanded, it has become
3479 depth of parentheses has been removed (though this was never a serious
3484 18. Fixed a minor bug in pcretest: if a pattern line was not terminated by a
3485 newline (only possible for the last line of a file) and it was a
3499 21. There was an incorrect error "recursive call could loop indefinitely" if
3500 a subpattern (or the entire pattern) that was being tested for matching an
3503 incorrectly, because the \d was being skipped in the check.
3517 24. A recursive reference to a subpattern whose number was greater than 39
3532 lookahead was broken if it was not anchored. PCRE was mistakenly expecting
3536 29. The ucpinternal.h header file was missing its idempotency #ifdef.
3538 30. I was sent a "project" file called libpcre.a.dev which I understand makes
3596 hyphen was adjacent to \Q or \E. I hope I've cleared all this up now.
3601 against aaaa the result was just "a" rather than "aaaa", for example. Two
3651 2. The code in pcre_study() was using the value of the re argument before
3657 was missing a "static" storage class specifier.
3659 4. When UTF-8 mode was not set, PCRE looped when compiling certain patterns
3667 correctly when UTF-8 mode was not set.]
3669 5. A negated single-character class was not being recognized as fixed-length
3673 6. The RunPerlTest auxiliary script was showing an unexpected difference
3676 byte characters or as UTF-8, which is what "perltest" was being required to
3682 7. In multiline (/m) mode, PCRE was matching ^ after a terminating newline at
3684 Perl does. This was true of both matching functions. Now it matches only at
3687 8. A call of pcre_fullinfo() from pcretest to get the option bits was passing
3694 10. There was no check on the number of named subpatterns nor the maximum
3703 the compiled pattern. The size of memory for this was computed from the
3705 65535, but there was no limit on the former, meaning that integer overflow
3722 PCRE_CASELESS was set when matching characters that were quantified with ?
3726 but no maximum quantifier - for example [ab]{6,} - was not handled
3766 with the documentation.] However, when a pattern was studied with
3772 dependency changed within the pattern. This was once needed for "required
3775 significant bit of the word, which was not previously used (hangover from
3776 the days when it was an int rather than a uint) to free up another bit for
3791 as (?P>B) was quantified, for example (xxx(?P>B)){3}, the calculation of
3815 1. Change 16(a) for 6.5 broke things, because PCRE_DATA_SCOPE was not defined
3828 1. When using the partial match feature with pcre_dfa_exec(), it was not
3843 (b) A binary zero was treated as data while matching, but terminated the
3844 output line if it was written out. This has been fixed: binary zeroes
3852 (d) When -B was used with -n, some line numbers in the output were one less
3857 (f) If -A or -C was used with -c (count only), some lines of context were
3876 3. A nasty bug was discovered in the handling of recursive patterns, that is,
3879 outside the recursion, there was a failure, the code tried to back up into
3881 possible, and the result was an incorrect result from the match.
3906 subtraction was done in the overall bitmap for a character class, meaning
3907 that a class such as [\x0c[:blank:]] was incorrect because \x0c would not
3931 contained two bugs: (a) use of int instead of size_t, and (b) it was not
3939 10. The debugging option of pcretest was not showing the NO_AUTO_CAPTURE flag.
3941 11. The POSIX flag REG_NOSUB is now supported. When a pattern that was compiled
4004 19. In UTF-8 mode, a backslash followed by a non-Ascii character was not
4026 25. The pcre.h file was built from pcre.h.in, but the only changes that were
4034 well. It is built from pcre-config.in, and one of the substitutions was the
4070 (a) If C++ support was not built, "make install" and "make test" still
4073 (b) There were problems when the value of CXX was explicitly set. Some
4079 backslash in a target when C++ was disabled. This confuses some
4099 1. There was no test for integer overflow of quantifier values. A construction
4105 2. Building PCRE using VPATH was broken. Hopefully it is now fixed.
4114 was compiled. This caused two problems: (a) If there were more than 100
4117 back references of the form \12, where the number was greater than 9, were
4128 1. There was one reference to the variable "posix" in pcretest.c that was not
4146 C++ stuff. This should fix a reported problem when a compiler was present,
4192 defined when compiling for Windows was sent to me. I have put it into the
4239 "<stdin>" was used.
4257 (o) The -s option was incorrectly implemented. For compatibility with other
4260 -q that suppresses the output of matching lines, which was what -s was
4266 11. The Makefile was not using the Autoconf-supported LDFLAGS macro properly.
4299 19. libpcre.pc was being incorrectly installed as executable.
4359 to find the match, as PCRE was deluded into thinking that the match had to
4363 character. This was a failing pattern: "(?!.bcd).*". The bug is now fixed.
4370 users. (Previously there was a macro definition, but it apparently wasn't
4383 that contained multibyte characters and which was followed by a quantifier.
4393 17. The generated file chartables.c was being created in the source directory
4395 source directory was different from the building directory, and was
4422 was compiled on a host of opposite endianness.
4434 would have been treated as zero, but if in addition "ovector" was passed as
4503 9. The prototype for memmove() for systems that don't have it was using
4504 size_t, but the inclusion of the header that defines size_t was later. I've
4521 12. A recursive reference to a subpattern that was within another subpattern
4525 that was OK.
4527 13. In pcretest, the buffer for reading a data line was set at 30K, but the
4528 buffer into which it was copied (for escape processing) was still set at
4533 that was followed by a possessive quantifier.
4536 libpcreposix.la because I was told this is needed for a parallel build to
4539 16. If a pattern that contained .* following optional items at the start was
4540 studied, the wrong optimizing data was generated, leading to matching
4550 127 and 255 was not handled correctly if the compiled pattern was studied.
4568 7. If a pattern was successfully studied, and the -d (or /D) flag was given to
4617 (iii) PCRE was using its character types table to recognize decimal and
4646 area. (PCRE was not checking for the UTF-8 mode flag, and trying to move
4680 As part of these changes, -no-undefined was removed again. This was reported
4686 . In the match_data structure, match_limit was an unsigned long int, whereas
4687 match_call_count was an int. I've made them both unsigned long ints.
4695 4. If PCRE was complied with UTF-8 support, but called without the PCRE_UTF8
4699 5. If PCRE was compiled with UTF-8 support, but called without the PCRE_UTF8
4701 whose value was between 128 and 255 caused PCRE to crash.
4708 needed, and a string in dftables.c that was longer than standard compilers are
4724 5. PCRE was failing to diagnose the case of two named groups with the same
4727 6. A problem with one of PCRE's optimizations was discovered. PCRE remembers a
4735 7. A lesser problem with the same optimization is that it was recording the
4737 right along the subject, even when the first match of the pattern was going to
4749 all kinds of weird effects. Example: /#/ was bad; /()#/ was bad; /a#/ was not.
4765 6. Perl 5.005 was a long time ago. It's time to amalgamate the tests that use
4794 10. SunOS4 doesn't have strtoul(). This was used only for unpicking the -o
4798 11. pcregrep was ending with code 0 instead of 2 for the commands "pcregrep" or
4809 13. A change of greediness default within a pattern was not taking effect at
4812 was abstracted outside.
4824 been the other way round. Some of this was related to change 7 above.
4842 19. Although correctly diagnosing a missing ']' in a character class, PCRE was
4845 20. PCRE was getting more memory than necessary for patterns with classes that
4858 24. When there was a very long string of literal characters (over 255 bytes
4860 much memory was required could be incorrect, leading to segfaults or other
4863 25. PCRE was incorrectly assuming anchoring (either to start of subject or to
4865 there was a subsequent back reference to those brackets. This meant that, for
4890 point fails. However, backtracking will occur if possible. [This was changed
4903 30. If pcregrep was called with the -l option and just a single file name, it
4904 output "<stdin>" if a match was found, instead of the file name.
4937 allow it to read and process whole directories in Win32. This code was
4960 38. There was a case of malloc(0) in the POSIX testing code in pcretest. Avoid
5073 pcre_extra block, that is, the value that was passed as the argument to
5074 pcre_malloc() when PCRE was getting memory in which to place the information
5124 match if the class was a negative one (e.g. [^ab]). This has been fixed.
5128 character was multibyte, either singly or repeated.
5176 2. If --disable-static was given, the building process failed when trying to
5177 build pcretest and pcregrep. (For some reason it was using libtool to compile
5184 1. The experimental UTF-8 code was completely screwed up. It was packing the
5238 6. pcre_exec() was referring to its "code" argument before testing that
5239 argument for NULL (and giving an error if it was NULL).
5244 8. Tiny buglet in pcretest: when pcre_fullinfo() was called to retrieve the
5245 options bits, the pointer it was passed was to an int instead of to an unsigned
5279 1. If an octal character was given, but the value was greater than \377, it
5280 was not getting masked to the least significant bits, as documented. This could
5313 1. If the pattern /((Z)+|A)*/ was matched agained ZABCDEFG it matched Z instead
5314 of ZA. This was just one example of several cases that could provoke this bug,
5315 which was introduced by change 9 of version 2.00. The code for breaking
5316 infinite loops after an iteration that matches an empty string was't working
5319 2. The pcretest program was not imitating Perl correctly for the pattern /a*/g
5325 was there because it doesn't seem to be needed, and it causes trouble on some
5343 was only one use in pcre.c, and writing it out to avoid strchr() probably gives
5353 (1) It was failing to install pcreposix.h.
5355 (2) It was overwriting the pcre.3 man page with the pcreposix.3 man page.
5374 5. The POSIX interface was broken in that it was just handing over the POSIX
5407 1. When startoffset was not zero and the pattern began with ".*", PCRE was not
5408 trying to match at the startoffset position, but instead was moving forward to
5411 2. pcretest was not making use of PCRE_NOTEMPTY when repeating for /g and /G,
5412 and could get into a loop if a null string was matched other than at the start
5445 7. Fixed bug: a zero repetition after a literal string (e.g. /abcde{0}/) was
5479 with \b or \B, though it was doing it for other lookbehind assertions. That is,
5491 when the subject string contained newline characters. PCRE was assuming
5501 1. For parenthesized subpatterns with repeats whose minimum was zero, the
5502 computation of the store needed to hold the pattern was incorrect (too large).
5510 compiled in such a way that the backtracking after subsequent failure was
5511 pessimal. Something like (a){0,3} was compiled as (a)?(a)?(a)? instead of
5512 ((a)((a)(a)?)?)? with disastrous performance if the maximum was of any size.
5611 value of one (e.g. [^x]{1,6} ) was not compiled correctly. This could lead to
5628 1. A pattern such as /((a)*)*/ was not being diagnosed as in error (unlimited
5644 PCRE_CASELESS was set at run time.
5655 3. Fixed memory leak which occurred when a regex with back references was
5661 5. Temporary memory was being obtained in the case where the passed offsets
5662 vector was exactly big enough.
5673 1. A erroneous regex with a missing opening parenthesis was correctly
5678 it was reported that one broken compiler failed on the former because "code" is
5684 fail on data ending with that character. (It was going on too far, and checking
5685 the next character, typically a binary zero.) This was specific to the
5712 form of a regex was going wrong in the case of back references followed by
5733 1. PCRE was failing to diagnose unlimited repeat of empty string for patterns
5752 1. Fixed bug in code for optimizing classes with only one character. It was
5774 fixed one that was wrong - it said "range out of order" when it meant "invalid
5855 1. /(b)|(:+)/ was computing an incorrect first character.
5884 (e.g. /a{1,3}/) was broken (I mis-optimized it).
5886 2. Caseless matching was not working in character classes if the characters in
5911 1. PCRE was failing to diagnose unlimited repeats of subpatterns that could
5912 match the empty string as in /(a*)*/. It was looping and ultimately crashing.
5914 2. PCRE was looping on encountering an indefinitely repeated back reference to