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 

Reply via email to