(*ACCEPT) inside a quantified group within a lookbehind triggers unexpectedly
Environment
- PCRE2 10.47 (2025-10-21)
- Windows 11, 8-bit library, UTF+UCP enabled
Summary
When (*ACCEPT) is matched inside a positive lookahead assertion, it should simply cause that assertion to succeed. However, unexpected backtracking and repeated matching occur for reasons unknown.
Full Pattern
\D\K(?=(.*$))(?<=^(?=(?:\D(?=\D*(\g-1.|\d)(?<=(.)))((?=\1$)(*ACCEPT))?+)+).{,99})|\d
Replacement: $3
Intended behavior: In a string like ab123 (several letters followed by several digits), insert one digit after each letter, deleting excess digits → a1b2.
Algorithm:
\D\K matches a letter, resets match start(?=(.*$)) captures the rest of the string (for positioning) → group 1- Lookbehind: the lookahead
(?=(?:\D...)+) iterates over all letters from ^
- Each iteration:
\g-1 references its own group, advancing through digits with each repetition of the + quantifier (1→12→123); (?<=(.)) captures the last digit of that sequence → group 3
((?=\1$)(*ACCEPT))?+ should stop when the remaining text equals group 1 — at that point, group 3 holds the correct digit for the current letter
Bug: wrong value in group 3
Test with ab123
Expected (second match, when \D matches b):
Actual:
Group 2 = 123
Group 3 = 3
Test with abcd123456789
The four \D matches produce group 3 values: 1, 3, 7, 6 — no discernible pattern.
Any insight into whether this is due to some special matching logic, or whether it might be triggered by a bug, would be greatly appreciated.
(Note: this text was translated from Chinese; apologies for any unclear phrasing.)
(*ACCEPT)inside a quantified group within a lookbehind triggers unexpectedlyEnvironment
Summary
When
(*ACCEPT)is matched inside a positive lookahead assertion, it should simply cause that assertion to succeed. However, unexpected backtracking and repeated matching occur for reasons unknown.Full Pattern
Replacement:
$3Intended behavior: In a string like
ab123(several letters followed by several digits), insert one digit after each letter, deleting excess digits →a1b2.Algorithm:
\D\Kmatches a letter, resets match start(?=(.*$))captures the rest of the string (for positioning) → group 1(?=(?:\D...)+)iterates over all letters from^\g-1references its own group, advancing through digits with each repetition of the+quantifier (1→12→123);(?<=(.))captures the last digit of that sequence → group 3((?=\1$)(*ACCEPT))?+should stop when the remaining text equals group 1 — at that point, group 3 holds the correct digit for the current letterBug: wrong value in group 3
Test with
ab123Expected (second match, when
\Dmatchesb):Actual:
Test with
abcd123456789The four
\Dmatches produce group 3 values: 1, 3, 7, 6 — no discernible pattern.Any insight into whether this is due to some special matching logic, or whether it might be triggered by a bug, would be greatly appreciated.
(Note: this text was translated from Chinese; apologies for any unclear phrasing.)