On Sun, 22 Jan 2012 21:22:50 +0400, Philip Hazel <[email protected]>
wrote:
Even so, there is the problem of returning a zero-length partial match.
I do not like this because, for a non-anchored pattern, you can *always*
(well, almost always) find a zero-length partial match. Consider
something simple like /abcd/ matched partially against "xyz". If
zero-length partial matches are permitted, it would return a partial
match at the end of the string, instead of no match. Is that useful?
I have assumed that it is not useful.
It no need to return zero-length partial match.
In my example
PCRE version 8.21 2011-12-12
/(?!b)(?<=a)/+
\P\Pa
0:
0+
PCRE must return 'no match' instead of 'match'.
I do not want to change the current behaviour(or at least not much)
because that would be incompatible and probably
somebody would get caught out.
In addition to my previous post:
Now let this string 'abc' arrive to application by another two chunks:
'ab' and 'c'.
Matching this chunks with 'partial hard' option results 'no match'.
Thus the matching result depends of how whole string was splitted by
chunks. This is what PCRE must not allow.
My opinion is that current PCRE behaviour is useless and can bring
difficulty detectable errors to user that organize multisegment matching.
I suggest to not keep it.
But desicion is yours of course.
Thanx.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
