On Sat, 21 Jan 2012, Graycode wrote:
I think the root cause is a few lines above the #include you showed
above from pcretest.c:
#define PCRE_INCLUDED
#undef PRIV
#define PRIV(name) name
#include pcre_tables.c
So PRIV(utf8_table3) within a compile of pcretest.c (and its included
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 Sun, 22 Jan 2012, Philip Hazel wrote:
I'll make up an appropriate patch and send it to you to try on the RC1
tarball.
If this is all one-off only applicable to building pcretest when
the base libary is a Windows DLL, then maybe just documenting a
consideration for pcre_tables.c in
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, Graycode wrote:
If this is all one-off only applicable to building pcretest when
the base libary is a Windows DLL, then maybe just documenting a
consideration for pcre_tables.c in NON-UNIX-USE (10) would suffice.
It already has mention of a new need for pcre_printint.c,
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
On Sun, 22 Jan 2012, Philip Hazel wrote:
What I don't know is whether building PCRE under Windows using one of
the standard methods (i.e. configure or cmake) works. I rather
suspect that it won't. *That* is why I think changes are needed.
I think this issue would hinder a Windows build only
