Lines Matching refs:groups
37 7. Another buffer overflow bug involved duplicate named groups with a
104 27. Similar to (4) above: in a pattern with duplicated named groups and an
185 However, it was failing to mark any other groups between the hightest
187 those groups contained whatever was previously there. An example is the
200 subroutine call (recursive or otherwise) if the number of captured groups
372 7. Fixed a bug concerned with zero-minimum possessive groups that could match
383 level, when possessive repeated groups should always return to a higher
589 string (which is used for indefinitely repeated groups to allow for
630 14. The code in pcre_compile.c for creating the table of named capturing groups
633 pass (on the stack unless there are more than 20 named groups, in which
636 shorter) and prepared the way for better handling of references to groups
659 19. The code for checking named groups as conditions, either for being set or
661 above). Processing unduplicated named groups should now be as fast at
662 numerical groups, and processing duplicated groups should be faster than
1201 any matched groups, this happens at the end of processing. In the case when
1230 1 to "aa" instead of to an empty string. The bug affected repeated groups
1247 possessively repeated groups, and atomic groups.
1329 4. (*MARK) settings inside atomic groups that do not contain any capturing
1527 18. Change 22 for version 13 caused atomic groups to use more stack. This is
1528 inevitable for groups that contain captures, but it can lead to a lot of
1530 groups that do not contain any capturing parentheses.
1601 calls to match() for possessively repeated groups such as (abc)++ when
1604 11. While implementing 10, a number of bugs in the handling of groups were
1667 branched capturing and non-capturing groups, repeated or not, and also to
1669 in PCRE) and also to nested atomic groups.
1675 24. The way atomic groups are processed by pcre_exec() has been changed so that
1953 be atomic by that change, but in the case of named groups, the amount of
2238 same bug. Such groups have to be quantified to be useful, or contained
2667 (an internal error was given). Such groups are now left in the compiled
3035 the size of patterns that contain repeated groups with explicit upper
3038 32-bit integer. However, it turns out that people want to use groups that
3197 for detecting groups that can match an empty string.
3202 bit of new cunning has reduced the workspace needed for groups with
3527 them into atomic groups such as ($>a+). Now they have their own opcodes,
3534 numbered groups.
3560 (a) Named groups can now be defined as (?<name>...) or (?'name'...) as well
3575 groups (named and numbered) that are never evaluated inline, but can be
3885 atomic groups. Thus, for example, (?R) is treated as if it were (?>(?R)).
4724 5. PCRE was failing to diagnose the case of two named groups with the same
5567 2. Allow quantification of (?>) groups, and make it work correctly.
5569 3. The first character computation wasn't working for (?>) groups.
5587 (?imsx-imsx:) non-capturing groups with option setting
5596 9. As in 5.005, unlimited repeated groups that could match an empty substring
