Lines Matching refs:groups
133 9. Yet another buffer overflow bug involved duplicate named groups with a
151 14. And yet another buffer overflow bug involving duplicate named groups, this
223 7. Another buffer overflow bug involved duplicate named groups with a
290 27. Similar to (4) above: in a pattern with duplicated named groups and an
371 However, it was failing to mark any other groups between the hightest
373 those groups contained whatever was previously there. An example is the
386 subroutine call (recursive or otherwise) if the number of captured groups
558 7. Fixed a bug concerned with zero-minimum possessive groups that could match
569 level, when possessive repeated groups should always return to a higher
775 string (which is used for indefinitely repeated groups to allow for
816 14. The code in pcre_compile.c for creating the table of named capturing groups
819 pass (on the stack unless there are more than 20 named groups, in which
822 shorter) and prepared the way for better handling of references to groups
845 19. The code for checking named groups as conditions, either for being set or
847 above). Processing unduplicated named groups should now be as fast at
848 numerical groups, and processing duplicated groups should be faster than
1387 any matched groups, this happens at the end of processing. In the case when
1416 1 to "aa" instead of to an empty string. The bug affected repeated groups
1433 possessively repeated groups, and atomic groups.
1515 4. (*MARK) settings inside atomic groups that do not contain any capturing
1713 18. Change 22 for version 13 caused atomic groups to use more stack. This is
1714 inevitable for groups that contain captures, but it can lead to a lot of
1716 groups that do not contain any capturing parentheses.
1787 calls to match() for possessively repeated groups such as (abc)++ when
1790 11. While implementing 10, a number of bugs in the handling of groups were
1853 branched capturing and non-capturing groups, repeated or not, and also to
1855 in PCRE) and also to nested atomic groups.
1861 24. The way atomic groups are processed by pcre_exec() has been changed so that
2139 be atomic by that change, but in the case of named groups, the amount of
2424 same bug. Such groups have to be quantified to be useful, or contained
2853 (an internal error was given). Such groups are now left in the compiled
3221 the size of patterns that contain repeated groups with explicit upper
3224 32-bit integer. However, it turns out that people want to use groups that
3383 for detecting groups that can match an empty string.
3388 bit of new cunning has reduced the workspace needed for groups with
3713 them into atomic groups such as ($>a+). Now they have their own opcodes,
3720 numbered groups.
3746 (a) Named groups can now be defined as (?<name>...) or (?'name'...) as well
3761 groups (named and numbered) that are never evaluated inline, but can be
4071 atomic groups. Thus, for example, (?R) is treated as if it were (?>(?R)).
4910 5. PCRE was failing to diagnose the case of two named groups with the same
5753 2. Allow quantification of (?>) groups, and make it work correctly.
5755 3. The first character computation wasn't working for (?>) groups.
5773 (?imsx-imsx:) non-capturing groups with option setting
5782 9. As in 5.005, unlimited repeated groups that could match an empty substring
