Lines Matching full:was

18 whatever the build configuration was. It now correctly says "\R matches all
25 issue was fixed for other kinds of repeat in release 10.20 by change 19, but
46   (a) List of error numbers in Runtest.bat corrected (it was not the same as in
66 15. If PCRE2 was built with a default match limit a lot greater than the
97 that matched an empty string, but never at the starting match offset, was not
108 23. The VERSION condition test was reading fractional PCRE2 version numbers
130 28. A (*MARK) name was not being passed back for positive assertions that were
138 code point was less than 256 and that were recognized by the lookup table
148 (?m) the compile phase got it right.) This bug was introduced by the
153 long time because in pcre2test the result of memmove() was being used, whereas
165 with only characters less than 0x100, the first class was incorrectly being
177 39. If the only branch in a conditional subpattern was anchored, the whole
178 subpattern was treated as anchored, when it should not have been, since the
182 40. A repeated conditional subpattern that could match an empty string was
192 42. If before the first match in a file that was being searched by pcre2grep
193 there was a line that was sufficiently long to cause the input buffer to be
195 was being adjusted incorrectly, and could cause an overflow warning from a code
233 11. pcre2grep was truncating components of file names to 128 characters when
239 to be closed (as for a non-assertion ACCEPT), which was wrong and could lead to
244 13. Multiline matching in pcre2grep was misbehaving if the pattern matched
246 subsequent lines. Behaviour was different with and without colouring, and
250 14. If --line-buffered was specified for pcre2grep when input was from a
255 in a given mode, it was also expected that at least one mode is available.
264 17. If a backreference with a minimum repeat count of zero was first in a
266 recorded. For example, for the pattern /(?=(a))\1?b/, "b" was incorrectly set
272 as in the pattern /(?=(a))\1?b/ caused this process to fail. This was an
274 a match, just its speed. (In fact, in this case, the starting 'a' was
294 23. Updated the pcre2demo.c demonstration program, which was missing the extra
300 pcre2grep when \K was used in an assertion when --colour was used or in
304 25. When PCRE2_FIRSTLINE without PCRE2_NO_START_OPTIMIZE was used in non-JIT
307 it was not tried at the newline.
310 code unit anywhere in the subject was missing when searching for one of a
312 pcre2_dfa_match(). This was a missing optimization rather than a bug.
321 This could not actually cause a crash because it was always used in a memcpy()
328 grumble. The value of NUMBER was 10000, but a fuzzer exceeded 5000 capturing
333 31. Auto-possessification at the end of a capturing group was dependent on what
335 incorrect behaviour when the group was called recursively from elsewhere in the
356 before release, but after the code was made available in the repository. These
361       a match, because the external block was being set from non-existent
365       size was greater than the initial frame vector on the stack) caused a
370   (c) Handling of (*VERB)s in recursions was wrong in some cases.
400 appearing later in the pattern was compiled with the PCRE2_ANCHORED option,
412 8. When the zero_terminate modifier was specified on a pcre2test subject line
415 empty string with zero_terminate. This was a bug in pcre2test, not the library.
429 13. When the 32-bit library was being tested by pcre2test, error messages that
430 were longer than 64 code units could cause a buffer overflow. This was a bug in
440 16. Since 10.21, if pcre2_match() was called with a null context, default
441 memory allocation functions were used instead of whatever was used when the
442 pattern was compiled.
564 52. Change 3(g) for 10.23 was a bit too zealous. If a hyphen that follows a
568 53. Related to 52, though PCRE2 was throwing an error for [[:digit:]-X] it was
587 There was a bug that caused this not to happen if a Unicode property item was
607   (e) A conditional recursion test such as (?(R)...) misbehaved if there was a
632 before release, but after the code was made available in the repository. Many
638   (a) An overall recursion such as (?0) inside a lookbehind assertion was not
641   (b) In utf mode, the length of a *MARK (or other verb) name was being checked
645   (c) In extended /x mode, characters whose code was greater than 255 caused
649   (d) The amount of memory needed for a compiled pattern was miscalculated if a
651       was of length zero.
660   (g) When reading a callout string, if the end delimiter was at the end of the
661       pattern one further code unit was read.
665   (i) An insufficient memory size was being computed for compiling with
668   (j) A conditional group with an assertion condition used more memory than was
673       overrun did not check when the final META_END item was added.
677       was set, unpredictable behaviour could occur. The underlying bug was
686   (o) If \Q was preceded by a quantified item, and the following \E was
687       followed by '?' or '+', and there was at least one literal character
694   (q) A conditional group that started with a callout was not doing the right
698   (r) If a character whose code point was greater than 0xffff appeared within
699       a lookbehind that was within another lookbehind, the calculation of the
721 8. When pcre2test was outputing information from a callout, the caret indicator
722 for the current position in the subject line was incorrect if it was after an
723 escape sequence for a character whose code point was greater than \x{ff}.
732 11. If pcre2grep was compiled with JIT support, but the library was compiled
734 done by editing config.h), pcre2grep was giving a JIT error. Now it detects
747 only when PCRE2_NO_START_OPTIMIZE was *not* set:
749     (a) A pattern such as (?=.*X)X$ was incorrectly optimized as if it needed
758 16. The "offset" modifier in pcre2test was not being ignored (as documented)
759 when the POSIX API was in use.
767 which started with .* inside a positive lookahead was incorrectly being
790 26. pcre2-config --libs-posix was listing -lpcre2posix instead of
791 -lpcre2-posix. Also, the CMake build process was building the library with the
806 31. Fix a bug in pcre2test that caused a crash when a locale was set either in
807 the current pattern or a previous one and a wide character was matched.
810 PCRE2_SUBSTITUTE_EXTENDED was set caused a segmentation fault (NULL
813 33. If the starting offset was specified as greater than the subject length in
816 34. When PCRE2 was compiled to use the heap instead of the stack for recursive
825 too many nested or recursive back references. If the limit was reached in
843 39. In a library with Unicode support, incorrect data was compiled for a
853 42. The limit in the auto-possessification code that was intended to catch
854 overly-complicated patterns and not spend too much time auto-possessifying was
896 its start; pcre2test was not handling this correctly when using the POSIX
897 interface (it was OK with the native interface).
911     * LC_ALL was displayed as "LCC_ALL";
921 searching for the referenced group in order to find the minimum length was
928 55. Issue 32 for 10.22 below was not correctly fixed. If pcre2grep in multiline
978 10. It has happened that pcre2test was accidentally linked with another POSIX
981 own data into the regex_t block. In one example the re_pcre2_code field was
992 callout was taken, making the program appearing to loop.
996 compiling workspace (which was diagnosed, but of course is not desirable).
1011 not do this, leading to bad output from pcre2test when it was checking for
1040 23. RunTest.bat was missing a "set type" line for test 22.
1042 24. The pcre2posix.c file was including pcre2_internal.h, and using some
1058 30. Due to an oversight, pcre2grep was not making use of JIT when available.
1065 code). Also changed smc-check=all to smc-check=all-non-file as was done for
1084 pcre2_match.c, in anticipation that this is needed for the same reason it was
1089 the same line" - but it was already over the end.
1127 processing them could involve a buffer overflow if the following character was
1131 /((?x)(*:0))#(?'/. Specifically: if a setting of (?x) was followed by a (*MARK)
1133 during the scan for named groups, and hence the external # was incorrectly
1134 treated as a comment and the invalid (?' at the end of the pattern was not
1135 diagnosed. This caused a buffer overflow during the real compile. This bug was
1143 example /(?C$[$)(?<]/, was incorrectly processed and could provoke a buffer
1144 overflow. This bug was discovered by Karl Skomski with the LLVM fuzzer.
1153 for example, /(?(R))*+/, was incorrectly compiled.
1158 13. An empty comment (?#) in a pattern was incorrectly processed and could
1159 provoke a buffer overflow. This bug was discovered by Karl Skomski with the
1168 first of these bugs was discovered by Karl Skomski with the LLVM fuzzer.
1171 pcre2_compile() to run for a very long time. This bug was found by the LLVM
1174 17. A missing closing parenthesis for a callout with a string argument was not
1175 being diagnosed, possibly leading to a buffer overflow. This bug was found by
1181 19. If (?R was followed by - or + incorrect behaviour happened instead of a
1182 diagnostic. This bug was discovered by Karl Skomski with the LLVM fuzzer.
1184 20. Another bug that was introduced by change 36 for 10.20: conditional groups
1185 whose condition was an assertion preceded by an explicit callout with a string
1187 This bug was discovered by Karl Skomski with the LLVM fuzzer.
1191 string if the final multi-byte UTF-8 character was truncated.
1204 25. If a pattern contained a back reference to a group whose number was
1211 (?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
1217 28. If pcre2grep was given the -q option with -c or -l, or when handling a
1221 control verbs. This issue was found by Karl Skomski with a custom LLVM fuzzer.
1224 because the old way was the cause of many issues. Now, conversion of the group
1228 detected at compile time. This re-writing was done in response to yet another
1231 31. A test for a back reference to a non-existent group was missing for items
1232 such as \987. This caused incorrect code to be compiled. This issue was found
1246 This issue was found by Karl Skomski with a custom LLVM fuzzer.
1249 repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
1251 38. A bug which was introduced by the single character repetition optimization
1252 was fixed.
1254 39. Match limit check added to recursion. This issue was found by Karl Skomski
1287 this work, the new command was added to several test files and the testing
1308 escape was being ignored.
1338 66. In the POSIX wrapper, if regerror() was given too small a buffer, it could
1342 replacement string was happening before the length setting when the replacement
1343 string was zero-terminated.
1348 69. There was no check for integer overflow for a replacement group number in
1353 digit was given after the decimal point, or if more than two digits were given.
1357 71. In pcre2_substitute() there was the possibility of reading one code unit
1364 73. The maximum lookbehind length was incorrectly calculated for patterns such
1378 78. (*NO_AUTO_POSSESS) was not working.
1427 by a single ASCII character in a class item, was incorrectly compiled in UCP
1430 96. [:punct:] in UCP mode was matching some characters in the range 128-255
1435 property was also in the class (if PCRE2_UCP is set, escapes such as \w are
1442 99. If PCRE2_AUTO_CALLOUT was set on a pattern that had a (?# comment between
1444 misbehaved. This bug was found by the LLVM fuzzer.
1447 offset as zero instead of where the invalidity was found.
1452 102. Similar to 99 above, if an isolated \E was present between an item and its
1453 qualifier when PCRE2_AUTO_CALLOUT was set, pcre2_compile() misbehaved. This bug
1454 was found by the LLVM fuzzer.
1457 was set when the pmatch argument was NULL. It now returns REG_INVARG.
1463 was found by the LLVM fuzzer.
1470 107. In a number of places pcre2_compile() was not handling NULL characters
1471 correctly, and pcre2test with the "bincode" modifier was not always correctly
1478 108. If a pattern that was compiled with PCRE2_EXTENDED started with white
1479 space or a #-type comment that was followed by (?-x), which turns off
1480 PCRE2_EXTENDED, and there was no subsequent (?x) to turn it on again,
1482 consequently mis-compiled it. This bug was found by the LLVM fuzzer. The fix
1485 PCRE2_INFO_ALLOPTIONS. In fact, this was an anachronism that should have
1489 PCRE2_ALT_VERBNAMES was set caused pcre2_compile() to malfunction. This bug
1490 was found by the LLVM fuzzer.
1513 error. This bug was discovered by the LLVM fuzzer.
1520 6. The pattern /(?(?!)^)/ caused references to random memory. This bug was
1523 7. The assertion (?!) is optimized to (*FAIL). This was not handled correctly
1524 when this assertion was used as a condition, for example (?(?!)a|b). In
1531 optimization. This infelicity was discovered by the LLVM fuzzer.
1535 because \S ensures they are all in the class. The code for doing this was
1537 compile the pattern, leading to a buffer overflow. This bug was discovered by
1541 other kinds of group caused stack overflow at compile time. This bug was
1545 between a subroutine call and its quantifier was incorrectly compiled, leading
1546 to buffer overflow or other errors. This bug was discovered by the LLVM fuzzer.
1548 12. The illegal pattern /(?(?<E>.*!.*)?)/ was not being diagnosed as missing an
1549 assertion after (?(. The code was failing to check the character after (?(?<
1550 for the ! or = that would indicate a lookbehind assertion. This bug was
1554 a fixed maximum following a group that contains a subroutine reference was
1555 incorrectly compiled and could trigger buffer overflow. This bug was discovered
1560 This bug was discovered by the LLVM fuzzer.
1562 15. The bug fixed in 14 was due to an integer variable that was unsigned when
1568 lookbehind assertion. This bug was discovered by the LLVM fuzzer.
1573 18. There was a similar problem to 17 in pcre2test for global matches, though
1576 19. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*),
1580 where backtracking after \C could crash. This set of bugs was discovered by the
1584 a very long time if mutual recursion was present many times in a pattern, for
1586 been implemented. This infelicity was discovered by the LLVM fuzzer.
1591 memory if the replication required a buffer to be extended, and it was not
1592 working properly in 16-bit and 32-bit modes. This issue was discovered by a
1600 25. Static linking against the PCRE2 library using the pkg-config module was
1607 error. This bug was discovered by the LLVM fuzzer.
1611 For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/. This bug was
1614 28. A repeated conditional group whose condition was a reference by name caused
1615 a buffer overflow if there was more than one group with the given name. This
1616 bug was discovered by the LLVM fuzzer.
1620 This bug was discovered by the LLVM fuzzer.
1624 buffer overflow at compile time. This bug was discovered by the LLVM fuzzer.
1633 provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
1645 code for handling forward references was contorted and led to several errors in
1649 37. There was no check for integer overflow in subroutine calls such as (?123).
1651 38. The table entry for \l in EBCDIC environments was incorrect, leading to its
1655 an empty string was repeated, it was not identified as matching an empty string
1658 40. In an EBCDIC environment, pcretest was mishandling the escape sequences
1661 41. In an EBCDIC environment, \a in a pattern was converted to the ASCII
1668 was achieved on certain patterns.
1674 45. When PCRE2 was compiled without Unicode support, the use of \p and \P gave
1678 46. \h within a class was incorrectly compiled in EBCDIC environments.
1693 another kind of back reference, but it was not setting the highest
1694 backreference number. This mattered only if pcre2_match() was called with an
1695 ovector that was too small to hold the capture, and there was no other kind of
1697 bug was that the condition was always treated as FALSE when the capture could
1708 documentation of PCRE2_INFO_SIZE was incorrect in stating that the size did not
1716 6. If a bug that caused pcre2_compile() to use more memory than allocated was
1722 PCRE2_DUPNAMES was not set caused the amount of memory needed for the pattern
1729 9. If an assertion that was used as a condition was quantified with a minimum
1731 repetition and could match an empty string, a segfault was likely. The pattern
1752 before it is accepted. Previously, in an environment where a locale was listed
1758 capturing group number without parentheses, the last character was incorrectly
1762 failed to allow the zero-repeat case if pcre2_match() was called with an
1769 was selected. (2) The file src/pcre2_serialize.c had not been added to the list
1779 21. "make distclean" was not removing config.h, a file that may be created for
1786 referenced subpattern not found" when an incorrect memory address was read.
1787 This bug was reported as "heap overflow", discovered by Kai Lu of Fortinet's
1788 FortiGuard Labs. (Added 24-March-2015: CVE-2015-2325 was given to this.)
1792 incorrect code to be compiled. This bug was reported as "heap overflow",
1794 CVE-2015-2326 was given to this.)
1804 that example, the range a-j was left out of the class.
1814 The code of the library was heavily revised as part of the new API
1824 2. The test program, now called pcre2test, was re-specified and almost
1839 a group containing one of these characters was greedily repeated, and during
1848 6. A pattern such as /()a/ was not setting the "first character must be 'a'"
1854 it was failing to mark any other groups between the highest capture so far and
1856 whatever was previously there. An example is the pattern /(x)|((*ACCEPT))/ when
1861 9. If an assertion used as a condition was quantified with a minimum of zero