Lines Matching refs:was

48 single digit, the code unit beyond d was being read (i.e. there was a read
52 handled by an optimization in JIT. Furthermore a wrong offset was used to
55 10. Unnoticed for many years was the fact that delimiters other than / in the
58 as delimiters, and it was just luck that they didn't go wrong with perltest.sh.
70 was set and PCRE2_NO_START_OPTIMIZE was not set. The optimization for finding
71 the start of a match was not resetting correctly after a failed match on the
85 everywhere, which was not previously the case. At the same time, the escape
99 the failure was not reported.
101 21. Test 2 was failing when run from a directory other than the source
102 directory. This failure was previously missed in RunTest because of 20 above.
123 destination of a backtrack. This feature was documented, and was carried over
125 was done for 10.30 has made this atomicizing unnecessary, and it is confusing
159 Instead, the (DEFINE) group was being processed, and if at the end of the
160 lookbehind, that end was not correctly recognized. Errors such as "lookbehind
179 19. The function for checking UTF-16 validity was returning an incorrect offset
180 for the start of the error when a high surrogate was not followed by a valid
182 PCRE2_MATCH_INVALID_UTF was set and a match started immediately following the
188 match "word" because the "move back" value was set to zero.
236 check on this was ever implemented. This omission has been rectified; it fixes
264      contained (*ACCEPT) inside a qualified group whose minimum repetition was
282 10. A (*MARK) value inside a successful condition was not being returned by the
283 interpretive matcher (it was returned by JIT). This bug has been mended.
291 12. The quantifier {1} was always being ignored, but this is incorrect when it
296 13. For partial matches, pcre2test was always showing the maximum lookbehind
298 actually look behind the start (because it was later in the pattern). Showing
304 14. DFA matching (using pcre2_dfa_match()) was not recognising a partial match
305 if the end of the subject was encountered in a lookahead (conditional or
316 within it, the nested lookbehind was not correctly processed. For example, if
317 /(?<=(?=(?<=a)))b/ was matched to "ab" it gave no match instead of matching
336 21. A branch that started with (*ACCEPT) was not being recognized as one that
339 22. Corrected pcre2_set_character_tables() tables data type: was const unsigned
350 that is remembered as a minimum length), the whole group's length was
354 27. The "rightmost consulted character" value was not always correct; in
362 search is caseless, it was doing so inefficiently, which ended up slowing down
363 the match drastically when the subject was very long. The revised code (a)
407 38. If a non-ASCII character was the first in a starting assertion in a
413 operation was incorrectly removed in r1136. Reported by Ralf Junker.
424 a greater than 1 fixed quantifier. This issue was found by Yunho Kim.
427 prior to release, fixed a bug that caused a crash if pcre2_substitute() was
446 hexadecimal digit" bit was removed. The default tables in
468 overflow if the heap limit was set very large. This could cause incorrect "heap
480 below was unnecessarily complicated, as inttypes.h is a Standard C header,
505 followed by ^ it was not recognized as anchored.
514 it was reported not to on other systems, causing the tests to fail.
527 27. Related to 26 above, PCRE2_BAD_ESCAPE_IS_LITERAL was affecting known escape
533 29. The pcre2_dfa_match() function was incorrectly handling conditional version
534 tests such as (?(VERSION>=0)...) when the version test was true. Incorrect
538 names, as Perl does. There was a small bug in this new code, found by
585 whatever the build configuration was. It now correctly says "\R matches all
592 issue was fixed for other kinds of repeat in release 10.20 by change 19, but
613   (a) List of error numbers in Runtest.bat corrected (it was not the same as in
633 15. If PCRE2 was built with a default match limit a lot greater than the
664 that matched an empty string, but never at the starting match offset, was not
675 23. The VERSION condition test was reading fractional PCRE2 version numbers
697 28. A (*MARK) name was not being passed back for positive assertions that were
705 code point was less than 256 and that were recognized by the lookup table
715 (?m) the compile phase got it right.) This bug was introduced by the
720 long time because in pcre2test the result of memmove() was being used, whereas
732 with only characters less than 0x100, the first class was incorrectly being
744 39. If the only branch in a conditional subpattern was anchored, the whole
745 subpattern was treated as anchored, when it should not have been, since the
749 40. A repeated conditional subpattern that could match an empty string was
759 42. If before the first match in a file that was being searched by pcre2grep
760 there was a line that was sufficiently long to cause the input buffer to be
762 was being adjusted incorrectly, and could cause an overflow warning from a code
800 11. pcre2grep was truncating components of file names to 128 characters when
806 to be closed (as for a non-assertion ACCEPT), which was wrong and could lead to
811 13. Multiline matching in pcre2grep was misbehaving if the pattern matched
813 subsequent lines. Behaviour was different with and without colouring, and
817 14. If --line-buffered was specified for pcre2grep when input was from a
822 in a given mode, it was also expected that at least one mode is available.
831 17. If a backreference with a minimum repeat count of zero was first in a
833 recorded. For example, for the pattern /(?=(a))\1?b/, "b" was incorrectly set
839 as in the pattern /(?=(a))\1?b/ caused this process to fail. This was an
841 a match, just its speed. (In fact, in this case, the starting 'a' was
861 23. Updated the pcre2demo.c demonstration program, which was missing the extra
867 pcre2grep when \K was used in an assertion when --colour was used or in
871 25. When PCRE2_FIRSTLINE without PCRE2_NO_START_OPTIMIZE was used in non-JIT
874 it was not tried at the newline.
877 code unit anywhere in the subject was missing when searching for one of a
879 pcre2_dfa_match(). This was a missing optimization rather than a bug.
888 This could not actually cause a crash because it was always used in a memcpy()
895 grumble. The value of NUMBER was 10000, but a fuzzer exceeded 5000 capturing
900 31. Auto-possessification at the end of a capturing group was dependent on what
902 incorrect behaviour when the group was called recursively from elsewhere in the
923 before release, but after the code was made available in the repository. These
928       a match, because the external block was being set from non-existent
932       size was greater than the initial frame vector on the stack) caused a
937   (c) Handling of (*VERB)s in recursions was wrong in some cases.
967 appearing later in the pattern was compiled with the PCRE2_ANCHORED option,
979 8. When the zero_terminate modifier was specified on a pcre2test subject line
982 empty string with zero_terminate. This was a bug in pcre2test, not the library.
996 13. When the 32-bit library was being tested by pcre2test, error messages that
997 were longer than 64 code units could cause a buffer overflow. This was a bug in
1007 16. Since 10.21, if pcre2_match() was called with a null context, default
1008 memory allocation functions were used instead of whatever was used when the
1009 pattern was compiled.
1131 52. Change 3(g) for 10.23 was a bit too zealous. If a hyphen that follows a
1135 53. Related to 52, though PCRE2 was throwing an error for [[:digit:]-X] it was
1154 There was a bug that caused this not to happen if a Unicode property item was
1174   (e) A conditional recursion test such as (?(R)...) misbehaved if there was a
1199 before release, but after the code was made available in the repository. Many
1205   (a) An overall recursion such as (?0) inside a lookbehind assertion was not
1208   (b) In utf mode, the length of a *MARK (or other verb) name was being checked
1212   (c) In extended /x mode, characters whose code was greater than 255 caused
1216   (d) The amount of memory needed for a compiled pattern was miscalculated if a
1218       was of length zero.
1227   (g) When reading a callout string, if the end delimiter was at the end of the
1228       pattern one further code unit was read.
1232   (i) An insufficient memory size was being computed for compiling with
1235   (j) A conditional group with an assertion condition used more memory than was
1240       overrun did not check when the final META_END item was added.
1244       was set, unpredictable behaviour could occur. The underlying bug was
1253   (o) If \Q was preceded by a quantified item, and the following \E was
1254       followed by '?' or '+', and there was at least one literal character
1261   (q) A conditional group that started with a callout was not doing the right
1265   (r) If a character whose code point was greater than 0xffff appeared within
1266       a lookbehind that was within another lookbehind, the calculation of the
1288 8. When pcre2test was outputing information from a callout, the caret indicator
1289 for the current position in the subject line was incorrect if it was after an
1290 escape sequence for a character whose code point was greater than \x{ff}.
1299 11. If pcre2grep was compiled with JIT support, but the library was compiled
1301 done by editing config.h), pcre2grep was giving a JIT error. Now it detects
1314 only when PCRE2_NO_START_OPTIMIZE was *not* set:
1316     (a) A pattern such as (?=.*X)X$ was incorrectly optimized as if it needed
1325 16. The "offset" modifier in pcre2test was not being ignored (as documented)
1326 when the POSIX API was in use.
1334 which started with .* inside a positive lookahead was incorrectly being
1357 26. pcre2-config --libs-posix was listing -lpcre2posix instead of
1358 -lpcre2-posix. Also, the CMake build process was building the library with the
1373 31. Fix a bug in pcre2test that caused a crash when a locale was set either in
1374 the current pattern or a previous one and a wide character was matched.
1377 PCRE2_SUBSTITUTE_EXTENDED was set caused a segmentation fault (NULL
1380 33. If the starting offset was specified as greater than the subject length in
1383 34. When PCRE2 was compiled to use the heap instead of the stack for recursive
1392 too many nested or recursive back references. If the limit was reached in
1410 39. In a library with Unicode support, incorrect data was compiled for a
1420 42. The limit in the auto-possessification code that was intended to catch
1421 overly-complicated patterns and not spend too much time auto-possessifying was
1463 its start; pcre2test was not handling this correctly when using the POSIX
1464 interface (it was OK with the native interface).
1478     * LC_ALL was displayed as "LCC_ALL";
1488 searching for the referenced group in order to find the minimum length was
1495 55. Issue 32 for 10.22 below was not correctly fixed. If pcre2grep in multiline
1545 10. It has happened that pcre2test was accidentally linked with another POSIX
1548 own data into the regex_t block. In one example the re_pcre2_code field was
1559 callout was taken, making the program appearing to loop.
1563 compiling workspace (which was diagnosed, but of course is not desirable).
1578 not do this, leading to bad output from pcre2test when it was checking for
1607 23. RunTest.bat was missing a "set type" line for test 22.
1609 24. The pcre2posix.c file was including pcre2_internal.h, and using some
1625 30. Due to an oversight, pcre2grep was not making use of JIT when available.
1632 code). Also changed smc-check=all to smc-check=all-non-file as was done for
1651 pcre2_match.c, in anticipation that this is needed for the same reason it was
1656 the same line" - but it was already over the end.
1694 processing them could involve a buffer overflow if the following character was
1698 /((?x)(*:0))#(?'/. Specifically: if a setting of (?x) was followed by a (*MARK)
1700 during the scan for named groups, and hence the external # was incorrectly
1701 treated as a comment and the invalid (?' at the end of the pattern was not
1702 diagnosed. This caused a buffer overflow during the real compile. This bug was
1710 example /(?C$[$)(?<]/, was incorrectly processed and could provoke a buffer
1711 overflow. This bug was discovered by Karl Skomski with the LLVM fuzzer.
1720 for example, /(?(R))*+/, was incorrectly compiled.
1725 13. An empty comment (?#) in a pattern was incorrectly processed and could
1726 provoke a buffer overflow. This bug was discovered by Karl Skomski with the
1735 first of these bugs was discovered by Karl Skomski with the LLVM fuzzer.
1738 pcre2_compile() to run for a very long time. This bug was found by the LLVM
1741 17. A missing closing parenthesis for a callout with a string argument was not
1742 being diagnosed, possibly leading to a buffer overflow. This bug was found by
1748 19. If (?R was followed by - or + incorrect behaviour happened instead of a
1749 diagnostic. This bug was discovered by Karl Skomski with the LLVM fuzzer.
1751 20. Another bug that was introduced by change 36 for 10.20: conditional groups
1752 whose condition was an assertion preceded by an explicit callout with a string
1754 This bug was discovered by Karl Skomski with the LLVM fuzzer.
1758 string if the final multi-byte UTF-8 character was truncated.
1771 25. If a pattern contained a back reference to a group whose number was
1778 (?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
1784 28. If pcre2grep was given the -q option with -c or -l, or when handling a
1788 control verbs. This issue was found by Karl Skomski with a custom LLVM fuzzer.
1791 because the old way was the cause of many issues. Now, conversion of the group
1795 detected at compile time. This re-writing was done in response to yet another
1798 31. A test for a back reference to a non-existent group was missing for items
1799 such as \987. This caused incorrect code to be compiled. This issue was found
1813 This issue was found by Karl Skomski with a custom LLVM fuzzer.
1816 repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
1818 38. A bug which was introduced by the single character repetition optimization
1819 was fixed.
1821 39. Match limit check added to recursion. This issue was found by Karl Skomski
1854 this work, the new command was added to several test files and the testing
1875 escape was being ignored.
1905 66. In the POSIX wrapper, if regerror() was given too small a buffer, it could
1909 replacement string was happening before the length setting when the replacement
1910 string was zero-terminated.
1915 69. There was no check for integer overflow for a replacement group number in
1920 digit was given after the decimal point, or if more than two digits were given.
1924 71. In pcre2_substitute() there was the possibility of reading one code unit
1931 73. The maximum lookbehind length was incorrectly calculated for patterns such
1945 78. (*NO_AUTO_POSSESS) was not working.
1994 by a single ASCII character in a class item, was incorrectly compiled in UCP
1997 96. [:punct:] in UCP mode was matching some characters in the range 128-255
2002 property was also in the class (if PCRE2_UCP is set, escapes such as \w are
2009 99. If PCRE2_AUTO_CALLOUT was set on a pattern that had a (?# comment between
2011 misbehaved. This bug was found by the LLVM fuzzer.
2014 offset as zero instead of where the invalidity was found.
2019 102. Similar to 99 above, if an isolated \E was present between an item and its
2020 qualifier when PCRE2_AUTO_CALLOUT was set, pcre2_compile() misbehaved. This bug
2021 was found by the LLVM fuzzer.
2024 was set when the pmatch argument was NULL. It now returns REG_INVARG.
2030 was found by the LLVM fuzzer.
2037 107. In a number of places pcre2_compile() was not handling NULL characters
2038 correctly, and pcre2test with the "bincode" modifier was not always correctly
2045 108. If a pattern that was compiled with PCRE2_EXTENDED started with white
2046 space or a #-type comment that was followed by (?-x), which turns off
2047 PCRE2_EXTENDED, and there was no subsequent (?x) to turn it on again,
2049 consequently mis-compiled it. This bug was found by the LLVM fuzzer. The fix
2052 PCRE2_INFO_ALLOPTIONS. In fact, this was an anachronism that should have
2056 PCRE2_ALT_VERBNAMES was set caused pcre2_compile() to malfunction. This bug
2057 was found by the LLVM fuzzer.
2080 error. This bug was discovered by the LLVM fuzzer.
2087 6. The pattern /(?(?!)^)/ caused references to random memory. This bug was
2090 7. The assertion (?!) is optimized to (*FAIL). This was not handled correctly
2091 when this assertion was used as a condition, for example (?(?!)a|b). In
2098 optimization. This infelicity was discovered by the LLVM fuzzer.
2102 because \S ensures they are all in the class. The code for doing this was
2104 compile the pattern, leading to a buffer overflow. This bug was discovered by
2108 other kinds of group caused stack overflow at compile time. This bug was
2112 between a subroutine call and its quantifier was incorrectly compiled, leading
2113 to buffer overflow or other errors. This bug was discovered by the LLVM fuzzer.
2115 12. The illegal pattern /(?(?<E>.*!.*)?)/ was not being diagnosed as missing an
2116 assertion after (?(. The code was failing to check the character after (?(?<
2117 for the ! or = that would indicate a lookbehind assertion. This bug was
2121 a fixed maximum following a group that contains a subroutine reference was
2122 incorrectly compiled and could trigger buffer overflow. This bug was discovered
2127 This bug was discovered by the LLVM fuzzer.
2129 15. The bug fixed in 14 was due to an integer variable that was unsigned when
2135 lookbehind assertion. This bug was discovered by the LLVM fuzzer.
2140 18. There was a similar problem to 17 in pcre2test for global matches, though
2143 19. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*),
2147 where backtracking after \C could crash. This set of bugs was discovered by the
2151 a very long time if mutual recursion was present many times in a pattern, for
2153 been implemented. This infelicity was discovered by the LLVM fuzzer.
2158 memory if the replication required a buffer to be extended, and it was not
2159 working properly in 16-bit and 32-bit modes. This issue was discovered by a
2167 25. Static linking against the PCRE2 library using the pkg-config module was
2174 error. This bug was discovered by the LLVM fuzzer.
2178 For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/. This bug was
2181 28. A repeated conditional group whose condition was a reference by name caused
2182 a buffer overflow if there was more than one group with the given name. This
2183 bug was discovered by the LLVM fuzzer.
2187 This bug was discovered by the LLVM fuzzer.
2191 buffer overflow at compile time. This bug was discovered by the LLVM fuzzer.
2200 provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
2212 code for handling forward references was contorted and led to several errors in
2216 37. There was no check for integer overflow in subroutine calls such as (?123).
2218 38. The table entry for \l in EBCDIC environments was incorrect, leading to its
2222 an empty string was repeated, it was not identified as matching an empty string
2225 40. In an EBCDIC environment, pcretest was mishandling the escape sequences
2228 41. In an EBCDIC environment, \a in a pattern was converted to the ASCII
2235 was achieved on certain patterns.
2241 45. When PCRE2 was compiled without Unicode support, the use of \p and \P gave
2245 46. \h within a class was incorrectly compiled in EBCDIC environments.
2260 another kind of back reference, but it was not setting the highest
2261 backreference number. This mattered only if pcre2_match() was called with an
2262 ovector that was too small to hold the capture, and there was no other kind of
2264 bug was that the condition was always treated as FALSE when the capture could
2275 documentation of PCRE2_INFO_SIZE was incorrect in stating that the size did not
2283 6. If a bug that caused pcre2_compile() to use more memory than allocated was
2289 PCRE2_DUPNAMES was not set caused the amount of memory needed for the pattern
2296 9. If an assertion that was used as a condition was quantified with a minimum
2298 repetition and could match an empty string, a segfault was likely. The pattern
2319 before it is accepted. Previously, in an environment where a locale was listed
2325 capturing group number without parentheses, the last character was incorrectly
2329 failed to allow the zero-repeat case if pcre2_match() was called with an
2336 was selected. (2) The file src/pcre2_serialize.c had not been added to the list
2346 21. "make distclean" was not removing config.h, a file that may be created for
2353 referenced subpattern not found" when an incorrect memory address was read.
2354 This bug was reported as "heap overflow", discovered by Kai Lu of Fortinet's
2355 FortiGuard Labs. (Added 24-March-2015: CVE-2015-2325 was given to this.)
2359 incorrect code to be compiled. This bug was reported as "heap overflow",
2361 CVE-2015-2326 was given to this.)
2371 that example, the range a-j was left out of the class.
2381 The code of the library was heavily revised as part of the new API
2391 2. The test program, now called pcre2test, was re-specified and almost
2406 a group containing one of these characters was greedily repeated, and during
2415 6. A pattern such as /()a/ was not setting the "first character must be 'a'"
2421 it was failing to mark any other groups between the highest capture so far and
2423 whatever was previously there. An example is the pattern /(x)|((*ACCEPT))/ when
2428 9. If an assertion used as a condition was quantified with a minimum of zero