Lines Matching refs:subject
77 for the current position in the subject line was incorrect if it was after
94 incorrectly optimized as having to match at the start of the subject or
242 \a and \e in test subject lines.
437 was combined with setting a null ovector, for example \O\C+ as a subject
518 the repeated \X did not stop, but carried on past the start of the subject,
797 (b) If the match point in a subject started with modifier character, and
799 point, and potentially beyond the first character in the subject,
1264 the subject string length, the error given was PCRE_ERROR_BADOFFSET, which
1311 subject.
1314 characters at the end of the subject.
1320 a partial match for a CR character at the end of the subject string.
1421 38. Wide characters specified with \uxxxx in JavaScript mode are now subject to
1456 match a (*MARK), and the match failed at the start of the subject, a
1457 reference to memory before the start of the subject could occur. This bug
1567 incorrectly expecting the subject to contain another "a" after the start.
1594 subject string.
1659 invalid errors such as "Error -26 (nested recursion at the same subject
1665 computing a minimum subject length in the presence of *ACCEPT is difficult
1719 suppress the check for a minimum subject length at run time. (If it was
1730 \x{...} escapes in subject strings. The has been rewritten to avoid using
1751 2-byte code at the end of the subject (it thought there wasn't enough data
1834 matched two bytes, thus causing the minimum subject length to be
1837 19. If a pattern containing (*ACCEPT) was studied, the minimum subject length
1858 subject after a captured substring, to make it easier to tell which of a
1933 same position in the subject string. In previous releases this might have
2039 match an empty string at the end of the subject); however the checking for
2043 example, /(?<=abc)def/ gives a partial match for the subject "abc"
2100 as a starting offset was within the subject string. There is now a new
2206 greater than 0xc0 were present in the subject string. (Detail: it assumed
2396 causing partial matching to fail when the end of the subject matched \W
2443 2. Changed the call to open a subject file in pcregrep from fopen(pathname,
2486 for the match and the offset of the end of the subject are set in them when
2495 used to be given if ever the end of the subject was reached; now it is
2569 length of subject string that was needed in order to match a given pattern.
2572 to the length of subject needed. It is not necessarily the greatest lower
2673 with the subject "ab", where knowledge that the repeated group can match
2773 pcre_dfa_exec() could read past the end of the passed subject if there was
2775 pcretest so that it places the subject at the end of its malloc-ed buffer.
3184 when the subject happened to end in the byte 0x85 (e.g. if the last
3252 past the start of the subject in the presence of bytes with the top bit
3271 for patterns like [\PPP\x8a]{1,}\x80 with the subject "A\x80".
3521 ^$ would give a match between the \r and \n of a subject such as "A\r\nB".
3575 (b) When it is outputting text that is a matched part of a subject string,
3869 the end of the subject string, contrary to the documentation and to what
3871 the start of the subject and immediately after *internal* newlines.
3904 pattern could run off the end of the subject. For example, the pattern
3905 "(?s)(.{1,5})"8 did this with the subject "ab".
4143 library, to replace subject pointers for pcre_exec() with a smart pointer
4194 (for example \pL{2,}), PCRE could look past the end of the subject if it
4384 match before or at the first newline in the subject string. In pcretest,
4404 over several lines of the subject. The buffering ensures that at least
4551 10. In UTF-8 mode, when moving forwards in the subject after a failed match
4552 starting at the last subject character, bytes beyond the end of the subject
4668 When matching the same subject several times, it may save resources to use
4709 (x(y(?2))z)? provoked this bug with a subject that got as far as the
4809 character types table is still used for matching digits in subject
4822 to read one or more bytes before the start of the subject string. Often this
4827 to try to read one or more bytes before the start of the subject string.
4830 UTF-8 support could misbehave in various ways if the subject string
4914 literal character that is needed in the subject for a match, and scans along to
4917 Problem: the scan can take a lot of time if the subject is very long (e.g.
4919 amount of subject to be scanned is less than 1000 bytes.
4923 right along the subject, even when the first match of the pattern was going to
5049 25. PCRE was incorrectly assuming anchoring (either to start of subject or to
5172 circumstances. The count starts from zero for each position in the subject
5599 of the subject.
5638 character in the pattern, and pre-searching the subject to ensure it is present
5654 2. Added an extra argument to pcre_exec() to supply an offset in the subject to
5667 the letter 'x'. On long subject strings, this gives a significant speed-up.
5677 when the subject string contained newline characters. PCRE was assuming
5681 must be retried after every newline in the subject.
5758 end of the subject) and add 5.005's \z, which really does match only at the
5759 very end of the subject.
