On Mon, 15 Jul 2019, ND via Pcre-dev wrote:
> This option is added ten years ago EXACTLY for multisegment matching.
> Please read a very first proposal post and thread about it. Thats how
> partial_hard is born:
> https://lists.exim.org/lurker/message/20090524.142622.cb850f3a.en.html
Your memory is much better than mine. :-) However, this does mean that
partial hard matching has been the way it is for 10 years. For this
reason alone, I am very reluctant to make a change, because somebody,
somewhere is probably relying on the current behaviour.
> With multisegment matching we want that matching result be exactly the same as
> if we match a whole subject at once!
That is a good point, but I'm not sure it can always be achieved, and I
am not happy with your example:
/c*+(?<=[bc])/aftertext
abc
0: c
0+
ab\=ph
0:
0+
Your pattern encodes the requirement "find zero or more c's preceded by
b or c". When the input is "ab" that is exactly what it has done, which
is why it shows a complete match. It would make no sense never to give a
full match when \=ph is used. This is surely correct:
/abc/
xyzabcdef\=ph
0: abc
I'm trying to understand what the conditions are for a change in
behaviour. The issue is what should happen when a possible "partial
match" situation occurs, but no characters have been inspected. This
happens in this example:
/c*+(?<=[bc])/aftertext
ab\=ph
0:
0+
If the subject is "abc" you get a partial match, because one character
has been inspected. So what should happen when a possible partial match
has not inspected any characters? These are the choices:
1. Backtrack, maybe find a complete match (happens now).
2. Give an immediate "no match" - wrong for the test above.
3. Return a partial match of no inspected characters - also wrong.
The last one is wrong in general because it means that all unanchored
patterns would give partial matches for example:
/abc/
xyz\=ph
I don't think it is right for that to yield a partial match. (I'm
assuming no start-up optimizations.)
> I'll be very happy if you try to reconsider your approach to PCRE_PARTIAL_HARD
> and totally associate this option with multisegment matching purposes. Because
> it's what it originally intended for.
> But tell please if you know about another practical use of this option that
> force you to change it's original aims.
The problem is that I don't know what people use it for. It's been
around for 10 years, and all my previous experience is that people use
software in all kinds of strange ways not foreseen by its creator.
I think the only compromise here is perhaps to add a new option, to give
changed behaviour, but I do not know what the change should be.
Aha! I think I have spotted how to distinguish between /c*+(?<=[bc])/
and /abc/. The first one will have a non-zero max lookbehind. So,
something like this is needed:
. Invent a new option called PCRE2_NOTEOS. This would do two things:
(1) $, \z, and \Z would never match. This would deal with the /\z/
example.
(2) If a hard partial match is possible, but no characters have been
inspected, AND max lookbehind is non-zero, return PCRE2_PARTIAL.
Otherwise backtrack as now.
I am not sure that I like that; it seems messy and hard to explain, but
at the moment it's the best I can come up with. More thought is needed,
especially to see if (2) is all that is required, and if it would
adversely affect other patterns.
Philip
--
Philip Hazel
