Lines Matching refs:mode
167 UCP mode. The POSIX class got lost, but only if the single character
170 45. [:punct:] in UCP mode was matching some characters in the range 128-255
277 mode. In that example, the range a-j was left out of the class.
296 such as \S in non-UCP mode, explicit wide characters (> 255) can be ignored
330 38. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*),
476 mode in which only the bottom 21 bits of 32-bit data items are used. To
550 22. A typo in the code meant that in ungreedy mode the max/min qualifier
588 6. In UTF mode, the code for checking whether a group could match an empty
593 UTF-8 mode). The effect was undefined: the group might or might not be
694 26. In UCP mode, \s was not matching two of the characters that Perl matches,
710 30. Updated perltest.pl to add /u (force Unicode mode) when /W (use Unicode
717 does in Unicode mode.
728 errors. Perl warns for these when in warning mode, but PCRE has no facility
740 37. In extended mode, Perl ignores spaces before a + that indicates a
846 gives some modest performance improvement in 8-bit mode.
1013 17. Fix JIT tests when UTF is disabled and both 8 and 16 bit mode are enabled.
1037 case-independence. In UTF-mode with UCP support, this uses the new data
1081 30. In 8-bit UTF-8 mode, pcretest failed to give an error for data codepoints
1235 38. Wide characters specified with \uxxxx in JavaScript mode are now subject to
1236 the same checks as \x{...} characters in non-JavaScript mode. Specifically,
1237 codepoints that are too big for the mode are faulted, and in a UTF mode,
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
1244 mode the bug would be provoked by values in the range 0xfc00 to 0xdc00. In
1254 mode, patterns that started with \h* or \R* might be incorrectly matched.
1275 totally wrong answers (in non-JavaScript-compatibility mode). For example,
1333 5. Supporting of \x, \U and \u in JavaScript compatibility mode based on the
1366 13. In non-UTF-8 mode, \C is now supported in lookbehinds and DFA matching.
1560 caselessly in UTF-8 mode when codes for the characters concerned were
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
1875 but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several
1906 mode when an empty string match preceded an ASCII character followed by
1941 character, that is, a byte less than 128. (In EBCDIC mode, the code is
1999 11. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was
2038 caused a problem in UTF-8 mode when pcre_study() was used to create a list
2043 UTF-8 mode. (When PCRE_UCP is set - see 9 above - the code is different
2463 characters (bytes) greater than 127 when not in UTF-8 mode.
2558 a UTF-8 string, even in non-UTF-8 mode. Now it generates a single byte in
2559 non-UTF-8 mode. If the value is greater than 255, it gives a warning about
2592 exec() might read past the end of the data buffer in UTF-8 mode.
2598 15. Lazy qualifiers were not working in some cases in UTF-8 mode. For example,
2726 codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer
2776 2. Negative specials like \S did not work in character classes in UTF-8 mode.
2882 22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.*
2997 2. The pattern .*$ when run in not-DOTALL UTF-8 mode with newline=any failed
3002 not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by
3005 3. A small performance improvement in the DOTALL UTF-8 mode .* case.
3065 12. A pattern like \X?\d or \P{L}?\d in non-UTF-8 mode could cause a backtrack
3084 17. Fixed another case of looking too far back in non-UTF-8 mode (cf 12 above)
3121 24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte
3124 25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop.
3215 12. If \p or \P was used in non-UTF-8 mode on a character greater than 127
3334 15. In multiline mode when the newline sequence was set to "any", the pattern
3396 length. The relevant options are -x, and -i in UTF-8 mode. The result was
3446 them, and removed "b" from the input mode under Windows.
3474 cunning way of running the real compile function in a "fake" mode that
3477 tests of the mode. This should make future maintenance and development
3518 went wrong under certain circumstances in UTF-8 mode. This bug could also
3549 escaped with \Q...\E, or parentheses in a #-comment in /x mode.
3614 mode.
3659 4. When UTF-8 mode was not set, PCRE looped when compiling certain patterns
3662 [\pZ]). Almost always one would set UTF-8 mode when processing such a
3667 correctly when UTF-8 mode was not set.]
3682 7. In multiline (/m) mode, PCRE was matching ^ after a terminating newline at
3717 15. In UTF-8 mode, with the PCRE_DOTALL option set, a quantified dot in the
3755 values greater than \377 illegal in non-UTF-8 mode. In UTF-8 mode they
4004 19. In UTF-8 mode, a backslash followed by a non-Ascii character was not
4020 23. Recognize \x{...} as a code point specifier, even when not in UTF-8 mode,
4201 9. A repeated \w when used in UTF-8 mode with characters greater than 256
4317 byte in the character in UTF-8 mode.
4365 10. In UTF-8 mode, when moving forwards in the subject after a failed match
4517 11. In UTF-8 mode, if a recursive reference (e.g. (?1)) followed a character
4549 1. In UTF-8 mode, a character class containing characters with values between
4586 10. By default, when in UTF-8 mode, PCRE now checks for valid UTF-8 strings at
4635 5. There were several places in the code where, in UTF-8 mode, PCRE would try
4640 6. A lookbehind at the start of a pattern in UTF-8 mode could also cause PCRE
4643 7. A lookbehind in a pattern matched in non-UTF-8 mode on a PCRE compiled with
4646 area. (PCRE was not checking for the UTF-8 mode flag, and trying to move
4832 mode. Unlike ".", it always matches newline, whatever the setting of
5131 mode, for example: \x{100}{2,3}.
5143 PCRE in UTF-8 mode.
5808 mode). The option can be set at compile or exec time.
