On Sat, 22 Jun 2019, ND via Pcre-dev wrote:
> /\A(?:a|(?=b)|.){50}\z/
> abc
> 0: abc
>
> when engine in a strange way decides that it was exactly 50 repetitions.
That is not an unlimited repeat, so there is no special action for
matching an empty string. Therefore, (?=b) matches 47 times. A
On 2019-06-22 08:51, ph10 wrote:
There must be plenty of examples where removing \z changes what is
matched. How about /[ab]*\z/ matched against "aaaxxxbbb"?
I believed it was obviously that we told about matching from one position
of subject. Sorry that I don't say it explicitly.
In your
On Sat, 22 Jun 2019, ND via Pcre-dev wrote:
> Successfull match of "X*\z" means that PCRE says: X CAN be successfully
> repeated until the very end of subject (let's the match is "abc" for example).
> When we use "X*" we want to say: repeat X as much as it can.
Yes, but there is special
Thanks a lot for clarifying docs and for your patience with me.
On 2019-06-21 16:18, ph10 wrote:
On Mon, 17 Jun 2019, ND via Pcre-dev wrote:
Second of my little concern is that "X*\z" and "X*" both matches and
matches
are different.
I understand why it is from procedural point of view.
On Mon, 17 Jun 2019, ND via Pcre-dev wrote:
> Chapter ISSUES WITH MULTI-SEGMENT MATCHING of pcre2partial.html includes item
> 2 with description how to process with lookbehind assertions.
>
> I think it's important to add to this algorithm a some words about "no match":
> If result of partial
On Wed, 25 Jan 2012, ND wrote:
I'm not sure that negative PCRE_INFO_MAX_LOOKBEHIND value will be
useful. IMHO there is no difference between zero length lookbehind and
no lookbehind. In this cases I suggest to return 0 as
PCRE_INFO_MAX_LOOKBEHIND value.
Yes, you are probably right there.
On Tue, 24 Jan 2012, ND wrote:
May be it can be useful to combine our approaches to reduce the number of
cases when zero-length partial match may occur?
So, zero-length partial match is allowed when:
1. it arises within a lookahead
AND
2. pattern have lookbehind with non-zero length
I
On 2012-01-24 10:22, Philip Hazel wrote:
PCRE could tell the application the maximum lookbehind length, but what
it cannot tell is whether there is a lookbehind further along the path
that is being matched. So I don't think it should change its result.
However, an application can choose to
On Mon, 23 Jan 2012, ND wrote:
No. If PCRE can not calculate the length of the longest lookbehind in pattern
then main application must know that string returned for a partial match may
be not long enough and may be more symbols needed to keep.
If PCRE can calculate the length of the
May be it can be useful to combine our approaches to reduce the number of
cases when zero-length partial match may occur?
So, zero-length partial match is allowed when:
1. it arises within a lookahead
AND
2. pattern have lookbehind with non-zero length
--
## List details at
PCRE version 8.21 2011-12-12
/(?!b)(?=a)/+
\P\Pa
0:
0+
In this case a partial match is not forced in the lookahead because no
characters have been inspected. So the lookahead succeeds and the restof
the pattern matches.
Thanx, I understand how it works in current PCRE version. But
On Sun, 22 Jan 2012, ND wrote:
Let whole string be 'abc' and we want to test it against pattern
'(?!b)(?=a)'. If we apply this pattern to whole string (without 'partial
hard') then result will be 'no match'.
Now let this string arrive to application by two chunks: 'a' and 'bc'.
Applying
On 2012-01-22 17:22, Philip Hazel 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
On Sun, 22 Jan 2012, ND wrote:
This problem is a part of more common problem: If pattern contains lookbehind
than it may have useful zero-length partial matches.
Yes. It is the lookbehind that causes all problem. But PCRE would have
to remember that the pattern contains lookbehinds - which it
14 matches
Mail list logo
