On Sat, 28 Aug 2010, ND wrote: > I'm afraid you don't remember practical reasons that I explained when I > offer you to add this ability (you later called it 'partial hard'). The > practical purpose is to process INCOMPLETE STRINGS in situations when > string is very long or when it comes to client by parts and client don't > know when it ends. > And what practical reasons governs present PCRE behaviour? Why that > initial conception changes?
There is no conception change. "Partial" has always been about partial matching, not about partial strings. That is just the way it is. Matching strings in parts is not possible in PCRE using pcre_exec() because it might have to backtrack into an early part. That's the "practical reason".[*] It is possible to do that kind of thing to some extent using pcre_dfa_exec(), but that has other limitations. (Note that PCRE_NOTEOL stops $ matching at the end of a string, by the way.) Philip [*] Consider something (silly) like (a*b|\w*z). If you fed it 10000 "a" characters in separate parts, and then there was no "b", it would want to jump back to the beginning to look for \w*. The bottom line is that pcre_exec() always needs the whole string to be available for matching. -- Philip Hazel -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
