Lines Matching refs:bytes
933 explicitly stated to be in bytes, never having been updated. I also added
1243 processing when bytes with values greater than 127 were present. In 16-bit
1406 22. A caseless match of a UTF-8 character whose other case uses fewer bytes did
1421 "starts with" bytes for the pattern, the data written to the file (though
1561 different numbers of bytes. For example, U+023A and U+2C65 are an upper
1562 and lower case pair, using 2 and 3 bytes, respectively. The main bugs were:
1648 matched two bytes, thus causing the minimum subject length to be
1934 characters from a string of bytes) have been redefined so as not to use
2007 setting up an incorrect bitmap of starting bytes, but fortunately it could
2012 possible starting bytes for non-anchored patterns.
2039 of bytes that can start a match. For \s, it was including 0x85 and 0xa0,
2042 bytes for UTF-8 encodings are set for characters greater than 127 when in
2116 The checks now trigger 100 bytes before the end of the workspace.
2463 characters (bytes) greater than 127 when not in UTF-8 mode.
3002 not-DOTALL UTF-8 mode, PCRE was advancing by bytes rather than by
3039 are longer than 30,000 bytes (though not repeat them that many times).
3066 past the start of the subject in the presence of bytes with the top bit
3203 alternatives. The 1000-alternative test pattern now uses 12 bytes of
3216 it matched the wrong number of bytes.
3380 3. It seems that there are systems where bytes whose values are greater than
3386 (a) When it is outputting text in the compiled version of a pattern, bytes
3425 line is "zero bytes in current character"), it caused compiler complaints.
3476 ever using a few hundred bytes of working memory and without too many
3707 now limited to 30,000 bytes in order to prevent this.
3845 are now no different to any other data bytes.
3999 number of entries, I extended their size from 6 bytes to 8 bytes to
4011 there is a check for at least the minimum number of bytes.
4136 allocation error. I've done the easy fix, which wastes 2 bytes for sensible
4366 starting at the last subject character, bytes beyond the end of the subject
4420 (iii) The F pattern option causes pcretest to flip the bytes in the 32-bit
4486 that it rejects (a) strings containing 0xfe or 0xff bytes and (b) strings
4621 table is now used for this - though it costs 256 bytes, a table is
4636 to read one or more bytes before the start of the subject string. Often this
4641 to try to read one or more bytes before the start of the subject string.
4645 contained bytes with the 0x80 bit set and the 0x40 bit unset in a lookbehind
4733 amount of subject to be scanned is less than 1000 bytes.
4858 24. When there was a very long string of literal characters (over 255 bytes
4859 without UTF support, over 250 bytes with UTF support), the computation of how
4915 links, but this can be changed to 3 or 4 bytes by --with-link-size when
4952 the length of the longest name used. The first two bytes of each entry are the
5015 The output is an integer that contains the number of bytes used for internal
5185 bytes in the wrong order. How dumb can you get?
