https://bugs.exim.org/show_bug.cgi?id=2182
--- Comment #7 from Philip Hazel <p...@hermes.cam.ac.uk> --- (In reply to John Tattarakis from comment #6) > Perhaps a hard > limit on iteration and/or a more sophisticated safeguard to detect cycles, > such as "make sure the overall state of backreferences is not a duplicate of > a past state", is called for. Yes indeed, though I suspect this is not possible because remembering all the past states is not something that happens or could easily be made to happen. I've just had a quick look at the code, and all it remembers is the state at the start of the iteration, and then only for groups that are not non-capturing and not conditionals. (There's something complicated here, whose details I've forgotten. Have to study my own code to try to remember how it works...) A cheating way of providing something of what you want would be to invent a new parameter "allow a capturing group to match an empty string up to N times", but I don't really like that idea. Actually (and I'm thinking aloud too), even that could be tricky - where to keep the count... I'll continue to think about this, but do not hold your breath. Nothing may ever happen. > Thanks again, and thank you for > taking such a hands-on approach to maintaining this brilliant bit of > software. I need something to keep my mind active in my retirement. :-) -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev