Lines Matching full:was

45 10. It has happened that pcre2test was accidentally linked with another POSIX
48 own data into the regex_t block. In one example the re_pcre2_code field was
59 callout was taken, making the program appearing to loop.
63 compiling workspace (which was diagnosed, but of course is not desirable).
78 not do this, leading to bad output from pcre2test when it was checking for
107 23. RunTest.bat was missing a "set type" line for test 22.
109 24. The pcre2posix.c file was including pcre2_internal.h, and using some
125 30. Due to an oversight, pcre2grep was not making use of JIT when available.
132 code). Also changed smc-check=all to smc-check=all-non-file as was done for
151 pcre2_match.c, in anticipation that this is needed for the same reason it was
156 the same line" - but it was already over the end.
194 processing them could involve a buffer overflow if the following character was
198 /((?x)(*:0))#(?'/. Specifically: if a setting of (?x) was followed by a (*MARK)
200 during the scan for named groups, and hence the external # was incorrectly
201 treated as a comment and the invalid (?' at the end of the pattern was not
202 diagnosed. This caused a buffer overflow during the real compile. This bug was
210 example /(?C$[$)(?<]/, was incorrectly processed and could provoke a buffer
211 overflow. This bug was discovered by Karl Skomski with the LLVM fuzzer.
220 for example, /(?(R))*+/, was incorrectly compiled.
225 13. An empty comment (?#) in a pattern was incorrectly processed and could
226 provoke a buffer overflow. This bug was discovered by Karl Skomski with the
235 first of these bugs was discovered by Karl Skomski with the LLVM fuzzer.
238 pcre2_compile() to run for a very long time. This bug was found by the LLVM
241 17. A missing closing parenthesis for a callout with a string argument was not
242 being diagnosed, possibly leading to a buffer overflow. This bug was found by
248 19. If (?R was followed by - or + incorrect behaviour happened instead of a
249 diagnostic. This bug was discovered by Karl Skomski with the LLVM fuzzer.
251 20. Another bug that was introduced by change 36 for 10.20: conditional groups
252 whose condition was an assertion preceded by an explicit callout with a string
254 This bug was discovered by Karl Skomski with the LLVM fuzzer.
258 string if the final multi-byte UTF-8 character was truncated.
271 25. If a pattern contained a back reference to a group whose number was
278 (?(R<digits>). This omission was discovered by Karl Skomski with the LLVM
284 28. If pcre2grep was given the -q option with -c or -l, or when handling a
288 control verbs. This issue was found by Karl Skomski with a custom LLVM fuzzer.
291 because the old way was the cause of many issues. Now, conversion of the group
295 detected at compile time. This re-writing was done in response to yet another
298 31. A test for a back reference to a non-existent group was missing for items
299 such as \987. This caused incorrect code to be compiled. This issue was found
313 This issue was found by Karl Skomski with a custom LLVM fuzzer.
316 repeats. This issue was found by Karl Skomski with a custom LLVM fuzzer.
318 38. A bug which was introduced by the single character repetition optimization
319 was fixed.
321 39. Match limit check added to recursion. This issue was found by Karl Skomski
354 this work, the new command was added to several test files and the testing
375 escape was being ignored.
405 66. In the POSIX wrapper, if regerror() was given too small a buffer, it could
409 replacement string was happening before the length setting when the replacement
410 string was zero-terminated.
415 69. There was no check for integer overflow for a replacement group number in
420 digit was given after the decimal point, or if more than two digits were given.
424 71. In pcre2_substitute() there was the possibility of reading one code unit
431 73. The maximum lookbehind length was incorrectly calculated for patterns such
445 78. (*NO_AUTO_POSSESS) was not working.
494 by a single ASCII character in a class item, was incorrectly compiled in UCP
497 96. [:punct:] in UCP mode was matching some characters in the range 128-255
502 property was also in the class (if PCRE2_UCP is set, escapes such as \w are
509 99. If PCRE2_AUTO_CALLOUT was set on a pattern that had a (?# comment between
511 misbehaved. This bug was found by the LLVM fuzzer.
514 offset as zero instead of where the invalidity was found.
519 102. Similar to 99 above, if an isolated \E was present between an item and its
520 qualifier when PCRE2_AUTO_CALLOUT was set, pcre2_compile() misbehaved. This bug
521 was found by the LLVM fuzzer.
524 was set when the pmatch argument was NULL. It now returns REG_INVARG.
530 was found by the LLVM fuzzer.
537 107. In a number of places pcre2_compile() was not handling NULL characters
538 correctly, and pcre2test with the "bincode" modifier was not always correctly
545 108. If a pattern that was compiled with PCRE2_EXTENDED started with white
546 space or a #-type comment that was followed by (?-x), which turns off
547 PCRE2_EXTENDED, and there was no subsequent (?x) to turn it on again,
549 consequently mis-compiled it. This bug was found by the LLVM fuzzer. The fix
552 PCRE2_INFO_ALLOPTIONS. In fact, this was an anachronism that should have
556 PCRE2_ALT_VERBNAMES was set caused pcre2_compile() to malfunction. This bug
557 was found by the LLVM fuzzer.
580 error. This bug was discovered by the LLVM fuzzer.
587 6. The pattern /(?(?!)^)/ caused references to random memory. This bug was
590 7. The assertion (?!) is optimized to (*FAIL). This was not handled correctly
591 when this assertion was used as a condition, for example (?(?!)a|b). In
598 optimization. This infelicity was discovered by the LLVM fuzzer.
602 because \S ensures they are all in the class. The code for doing this was
604 compile the pattern, leading to a buffer overflow. This bug was discovered by
608 other kinds of group caused stack overflow at compile time. This bug was
612 between a subroutine call and its quantifier was incorrectly compiled, leading
613 to buffer overflow or other errors. This bug was discovered by the LLVM fuzzer.
615 12. The illegal pattern /(?(?<E>.*!.*)?)/ was not being diagnosed as missing an
616 assertion after (?(. The code was failing to check the character after (?(?<
617 for the ! or = that would indicate a lookbehind assertion. This bug was
621 a fixed maximum following a group that contains a subroutine reference was
622 incorrectly compiled and could trigger buffer overflow. This bug was discovered
627 This bug was discovered by the LLVM fuzzer.
629 15. The bug fixed in 14 was due to an integer variable that was unsigned when
635 lookbehind assertion. This bug was discovered by the LLVM fuzzer.
640 18. There was a similar problem to 17 in pcre2test for global matches, though
643 19. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*),
647 where backtracking after \C could crash. This set of bugs was discovered by the
651 a very long time if mutual recursion was present many times in a pattern, for
653 been implemented. This infelicity was discovered by the LLVM fuzzer.
658 memory if the replication required a buffer to be extended, and it was not
659 working properly in 16-bit and 32-bit modes. This issue was discovered by a
667 25. Static linking against the PCRE2 library using the pkg-config module was
674 error. This bug was discovered by the LLVM fuzzer.
678 For example, in this pattern: /(?1)()((((((\1++))\x85)+)|))/. This bug was
681 28. A repeated conditional group whose condition was a reference by name caused
682 a buffer overflow if there was more than one group with the given name. This
683 bug was discovered by the LLVM fuzzer.
687 This bug was discovered by the LLVM fuzzer.
691 buffer overflow at compile time. This bug was discovered by the LLVM fuzzer.
700 provoke a buffer overflow. This bug was discovered by the LLVM fuzzer.
712 code for handling forward references was contorted and led to several errors in
716 37. There was no check for integer overflow in subroutine calls such as (?123).
718 38. The table entry for \l in EBCDIC environments was incorrect, leading to its
722 an empty string was repeated, it was not identified as matching an empty string
725 40. In an EBCDIC environment, pcretest was mishandling the escape sequences
728 41. In an EBCDIC environment, \a in a pattern was converted to the ASCII
735 was achieved on certain patterns.
741 45. When PCRE2 was compiled without Unicode support, the use of \p and \P gave
745 46. \h within a class was incorrectly compiled in EBCDIC environments.
760 another kind of back reference, but it was not setting the highest
761 backreference number. This mattered only if pcre2_match() was called with an
762 ovector that was too small to hold the capture, and there was no other kind of
764 bug was that the condition was always treated as FALSE when the capture could
775 documentation of PCRE2_INFO_SIZE was incorrect in stating that the size did not
783 6. If a bug that caused pcre2_compile() to use more memory than allocated was
789 PCRE2_DUPNAMES was not set caused the amount of memory needed for the pattern
796 9. If an assertion that was used as a condition was quantified with a minimum
798 repetition and could match an empty string, a segfault was likely. The pattern
819 before it is accepted. Previously, in an environment where a locale was listed
825 capturing group number without parentheses, the last character was incorrectly
829 failed to allow the zero-repeat case if pcre2_match() was called with an
836 was selected. (2) The file src/pcre2_serialize.c had not been added to the list
846 21. "make distclean" was not removing config.h, a file that may be created for
853 referenced subpattern not found" when an incorrect memory address was read.
854 This bug was reported as "heap overflow", discovered by Kai Lu of Fortinet's
855 FortiGuard Labs. (Added 24-March-2015: CVE-2015-2325 was given to this.)
859 incorrect code to be compiled. This bug was reported as "heap overflow",
861 CVE-2015-2326 was given to this.)
871 that example, the range a-j was left out of the class.
881 The code of the library was heavily revised as part of the new API
891 2. The test program, now called pcre2test, was re-specified and almost
906 a group containing one of these characters was greedily repeated, and during
915 6. A pattern such as /()a/ was not setting the "first character must be 'a'"
921 it was failing to mark any other groups between the highest capture so far and
923 whatever was previously there. An example is the pattern /(x)|((*ACCEPT))/ when
928 9. If an assertion used as a condition was quantified with a minimum of zero