Lines Matching refs:mode
101 mode. In that example, the range a-j was left out of the class.
120 such as \S in non-UCP mode, explicit wide characters (> 255) can be ignored
154 38. If a greedy quantified \X was preceded by \C in UTF mode (e.g. \C\X*),
300 mode in which only the bottom 21 bits of 32-bit data items are used. To
374 22. A typo in the code meant that in ungreedy mode the max/min qualifier
412 6. In UTF mode, the code for checking whether a group could match an empty
417 UTF-8 mode). The effect was undefined: the group might or might not be
518 26. In UCP mode, \s was not matching two of the characters that Perl matches,
534 30. Updated perltest.pl to add /u (force Unicode mode) when /W (use Unicode
541 does in Unicode mode.
552 errors. Perl warns for these when in warning mode, but PCRE has no facility
564 37. In extended mode, Perl ignores spaces before a + that indicates a
670 gives some modest performance improvement in 8-bit mode.
837 17. Fix JIT tests when UTF is disabled and both 8 and 16 bit mode are enabled.
861 case-independence. In UTF-mode with UCP support, this uses the new data
905 30. In 8-bit UTF-8 mode, pcretest failed to give an error for data codepoints
1059 38. Wide characters specified with \uxxxx in JavaScript mode are now subject to
1060 the same checks as \x{...} characters in non-JavaScript mode. Specifically,
1061 codepoints that are too big for the mode are faulted, and in a UTF mode,
1065 matcher there was code that should only have been obeyed in UTF mode, but
1066 was being obeyed unconditionally. In 8-bit mode this could cause incorrect
1068 mode the bug would be provoked by values in the range 0xfc00 to 0xdc00. In
1078 mode, patterns that started with \h* or \R* might be incorrectly matched.
1099 totally wrong answers (in non-JavaScript-compatibility mode). For example,
1157 5. Supporting of \x, \U and \u in JavaScript compatibility mode based on the
1190 13. In non-UTF-8 mode, \C is now supported in lookbehinds and DFA matching.
1384 caselessly in UTF-8 mode when codes for the characters concerned were
1641 matched in multiline mode, the following line was shown as part of the
1644 6. Another pcregrep bug in multiline mode, when --colour was specified, caused
1699 but *byte* 0x85 is not, in UTF-8 mode). This bug was present in several
1730 mode when an empty string match preceded an ASCII character followed by
1765 character, that is, a byte less than 128. (In EBCDIC mode, the code is
1823 11. In UTF-8 mode, if a pattern that was compiled with PCRE_CASELESS was
1862 caused a problem in UTF-8 mode when pcre_study() was used to create a list
1867 UTF-8 mode. (When PCRE_UCP is set - see 9 above - the code is different
2287 characters (bytes) greater than 127 when not in UTF-8 mode.
2382 a UTF-8 string, even in non-UTF-8 mode. Now it generates a single byte in
2383 non-UTF-8 mode. If the value is greater than 255, it gives a warning about
2416 exec() might read past the end of the data buffer in UTF-8 mode.
2422 15. Lazy qualifiers were not working in some cases in UTF-8 mode. For example,
2550 codepoints greater than 255 (in UTF-8 mode, of course) caused a buffer
2600 2. Negative specials like \S did not work in character classes in UTF-8 mode.
2706 22. In UTF-8 mode, with newline set to "any", a pattern such as .*a.*=.b.*
2821 2. The pattern .*$ when run in not-DOTALL UTF-8 mode with newline=any failed
2826 not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by
2829 3. A small performance improvement in the DOTALL UTF-8 mode .* case.
2889 12. A pattern like \X?\d or \P{L}?\d in non-UTF-8 mode could cause a backtrack
2908 17. Fixed another case of looking too far back in non-UTF-8 mode (cf 12 above)
2945 24. A repeated \S or \W in UTF-8 mode could give wrong answers when multibyte
2948 25. Using pcregrep in multiline, inverted mode (-Mv) caused it to loop.
3039 12. If \p or \P was used in non-UTF-8 mode on a character greater than 127
3158 15. In multiline mode when the newline sequence was set to "any", the pattern
3220 length. The relevant options are -x, and -i in UTF-8 mode. The result was
3270 them, and removed "b" from the input mode under Windows.
3298 cunning way of running the real compile function in a "fake" mode that
3301 tests of the mode. This should make future maintenance and development
3342 went wrong under certain circumstances in UTF-8 mode. This bug could also
3373 escaped with \Q...\E, or parentheses in a #-comment in /x mode.
3438 mode.
3483 4. When UTF-8 mode was not set, PCRE looped when compiling certain patterns
3486 [\pZ]). Almost always one would set UTF-8 mode when processing such a
3491 correctly when UTF-8 mode was not set.]
3506 7. In multiline (/m) mode, PCRE was matching ^ after a terminating newline at
3541 15. In UTF-8 mode, with the PCRE_DOTALL option set, a quantified dot in the
3579 values greater than \377 illegal in non-UTF-8 mode. In UTF-8 mode they
3828 19. In UTF-8 mode, a backslash followed by a non-Ascii character was not
3844 23. Recognize \x{...} as a code point specifier, even when not in UTF-8 mode,
4025 9. A repeated \w when used in UTF-8 mode with characters greater than 256
4141 byte in the character in UTF-8 mode.
4189 10. In UTF-8 mode, when moving forwards in the subject after a failed match
4341 11. In UTF-8 mode, if a recursive reference (e.g. (?1)) followed a character
4373 1. In UTF-8 mode, a character class containing characters with values between
4410 10. By default, when in UTF-8 mode, PCRE now checks for valid UTF-8 strings at
4459 5. There were several places in the code where, in UTF-8 mode, PCRE would try
4464 6. A lookbehind at the start of a pattern in UTF-8 mode could also cause PCRE
4467 7. A lookbehind in a pattern matched in non-UTF-8 mode on a PCRE compiled with
4470 area. (PCRE was not checking for the UTF-8 mode flag, and trying to move
4656 mode. Unlike ".", it always matches newline, whatever the setting of
4955 mode, for example: \x{100}{2,3}.
4967 PCRE in UTF-8 mode.
5632 mode). The option can be set at compile or exec time.
