Re: [pcre-dev] 'Hard' partial matching don't work with some …

Top Page
Delete this message
Author: ND
Date:  
To: Pcre-dev
Subject: Re: [pcre-dev] 'Hard' partial matching don't work with some assertions
>
> I do not know. PCRE was not designed to work with multisegment strings.
>

In 2009 I propose 'hard' option exactly to work with multisegment strings.
I don't know necessity of 'hard' option without this aim.

> [Idea: if you get a match and the match ends at the end of your segment,
> add the next segment and try again?]
>

Thanx, i did so.

>> Say, please, what appliance to 'hard' option kepped in mind if it can
>> not
>> operate with multisegment strings?
>
> "Hard" prefers a partial match to a later, complete match (as described
> in the "pcrepartial" document. "Soft" prefers a later, complete match if
> it can find one.
>

No. May be my English is poor, sorry. I don't ask about how it works. What
practical tasks needs to use PCRE with this form of 'hard' option? You
say, this option is not for a long/multisegment string matching. But what
for?

>
> I will not change current behaviour because there may be people who are
> relying on it. Compatibility is important.
>
> In theory, perhaps, a new option could be added. However, I am now
> retired (and getting old and more forgetful) and I do not think I will
> have the desire, or the time, to add new features to PCRE, though I do
> still mend bugs.
>

I treat that is not new principial change. And what for are two options:
'hard' and new option? I think there is (and was) only one task - using
PCRE to process multisegment data. And it need one option. And present
'hard' option needs very little correction to deal right with certain
lookahead assertions.

As example I really don't understant *practical reasons* WHY for subject
string 'cat' analogous patterns returns different result:
pattern 't\b' returns 'ERROR_PARTIAL'
pattern 't\K\b' returns 'MATCH'
I read in documentation that partial match can never be an empty string.
But WHY? What idea is? What benefits are?


> Presumably, the restrictions for pcre_dfa_exec() mean that you can't use
> it? It is more straightforward to handle multisegment strings with
> pcre_dfa_exec(), but it does behave in a very different way.
>

pcre_dfa_exec() can not help. Only pcre_exec() can.


> I am sorry that I have misunderstood you during this thread; I plead old
> age.

I'm sorry too, I can't find precise words due to my bad English.