On Wed, 19 Jun 2019, ND via Pcre-dev wrote:
> >At present, lookarounds do not take part in minimum length calculations,
>
> I see lookarounds takes part: first and last code units are searched in
> lookarounds too.
I wasn't quite precise. Lookarounds are not scanned when computing
a minimum
On 2019-06-20 15:53, ph10 wrote:
I have updated the doc to use your example, but it can be done easily
with other PCRE2 facilities:
(?|(ab)c|(a))
does the same thing. If "a" is complex, and you do not want to write it
out twice, you could DEFINE it and use a subroutine call.
I don't say
On Sun, 16 Jun 2019, ND via Pcre-dev wrote:
> A following example was included in docs (pcre2pattern.html) :
>
> A(*ACCEPT)??BC
>
> But this example does not show what we can do with (*ACCESS)?? that can't
> doing well with another PCRE facilities.
> I suggest to show in docs another example
On 2019-06-19 17:15, ph10 wrote:
At present, lookarounds do not take part in minimum length calculations,
I see lookarounds takes part: first and last code units are searched in
lookarounds too.
So this is another reason in opposition to my poroposal.
So I suggest to close this thread.
On Wed, 19 Jun 2019, ND via Pcre-dev wrote:
> (*ACCEPT) can't leave lookaround borders. So ACCEPT's that are inside
> lookarounds can't influence minimum length claculation, if lookaround entrails
> are not participate in this calculation (is this true?).
>
> Thus more preferable may be to turn
(*ACCEPT) can't leave lookaround borders. So ACCEPT's that are inside
lookarounds can't influence minimum length claculation, if lookaround
entrails are not participate in this calculation (is this true?).
Thus more preferable may be to turn off minimum length scan not for all
patterns
On Mon, 17 Jun 2019, ND via Pcre-dev wrote:
> >If a pattern contains (*ACCEPT) the code for finding the minimum length
> >gives up because everything gets too complicated, and so the minimum is
> >0.
>
> Yes, it should. But it not 0, it is 2 in example from this thread:
>
>
It seems you don't understand or I don't. Sorry for my bad English.
I don't ask to calculate real subject_length_lower_bound in patterns with
ACCEPT.
I ask to set subject_length_lower_bound to 0 in all such patterns.
On 2019-06-17 15:07, ph10 wrote:
If a pattern contains (*ACCEPT) the
On Mon, 17 Jun 2019, ND via Pcre-dev wrote:
> I don't so this fix in PCRE2 source code repository.
> Is there plans to fix it as it doing with another patterns with ACCEPT?
>
> For example studying a pattern
>
> /a(*ACCEPT)/
>
> produce
> Subject length lower bound = 0
If a pattern contains
On 2019-06-04 16:59, ND wrote:
1. Start optimizer brakes a result to "no match" from "match". Is there
documented (I remember only example with (*COMMIT) where optimizer can
make "match" from "no match")? May be there is a way to correct this
PCRE optimization to not break a result.
I
On 2019-06-10 16:47, ph10 wrote:
I have done this, and committed the result. However, it seems to me that
/a(*ACCEPT)??bc/ is the same as a(?:bc|) though if a, b, and c are
complex it may be easier to read.
A following example was included in docs (pcre2pattern.html) :
A(*ACCEPT)??BC
On Wed, 5 Jun 2019, ND via Pcre-dev wrote:
> It seems a bug of Perl start optimizer. It say:
> "Did not find floating substr "bc"...
> Match rejected by optimizer"
>
> Please look at PCRE start optimizer.
PCRE2 does not record "c" as necessary after (*ACCEPT). So it does not
have this bug.
On 2019-06-05 16:53, ph10 wrote:
Perl gets it wrong:
/(a(?:(*ACCEPT))??bc)/
axy
No match
/a(*ACCEPT)??bc/
axy
No match
It seems a bug of Perl start optimizer. It say:
"Did not find floating substr "bc"...
Match rejected by optimizer"
Please look at PCRE start optimizer. It seems correction
On Wed, 5 Jun 2019, I wrote:
> On Wed, 5 Jun 2019, ND via Pcre-dev wrote:
>
> > It's not true for (*ACCEPT).
> > Construct "(*ACCEPT)??" is like a negated (*COMMIT) pattern:
> > (*COMMIT) immediately fail a whole match when backtrack to it occurs
> > (*ACCEPT)?? immediately match when backtrack
On Wed, 5 Jun 2019, ND via Pcre-dev wrote:
> It's not true for (*ACCEPT).
> Construct "(*ACCEPT)??" is like a negated (*COMMIT) pattern:
> (*COMMIT) immediately fail a whole match when backtrack to it occurs
> (*ACCEPT)?? immediately match when backtrack to it occurs
Ah, that is an interesting
Repetition is allowed for groups such as (?:...) but not for individual
backtracking verbs
It seems Perl does not rise error with "(*ACCEPT)??". And generates
expected code.
Is there weighty reason to be not compatible with Perl in this situation?
(for which it is meaningless).
It's
On Tue, 4 Jun 2019, ND via Pcre-dev wrote:
> PCRE2 version 10.33 2019-04-16
> /A(?:(*ACCEPT))?B/
> A
> No match
>
> /A(?:(*ACCEPT))?B/no_start_optimize
> A
> 0: A
>
> /A(*ACCEPT)?B/
> Failed: error 109 at offset 10: quantifier does not follow a repeatable item
> A
>
>
> I have a two questions
Good day!
Here is pcre2test listing:
PCRE2 version 10.33 2019-04-16
/A(?:(*ACCEPT))?B/
A
No match
/A(?:(*ACCEPT))?B/no_start_optimize
A
0: A
/A(*ACCEPT)?B/
Failed: error 109 at offset 10: quantifier does not follow a repeatable
item
A
I have a two questions with it:
1. Start
18 matches
Mail list logo
