On Sun, 29 Dec 2013, ND wrote:
May be better way is to document that if start position is greater then end
position, then start position value sets to end position value.
What do other people think about this idea? It is, of course, easy to
implement.
Or ignore \K in all assertions.
It is
On 2013-12-28 20:00, ph10 wrote:
A different application canchose to make a different interpretation of
the values that the PCRElibrary returns (which in this case are 2 for
the start ad 0 for theend).
I guess many real applications can generate unpredictable results (alike
pcretest.exe)
On Thu, 26 Dec 2013, Zoltán Herczeg wrote:
I didn't know it is accidental. I thought printing an empty string is
less useful for a testing tool. Perhaps printing the offsets
themselves would be the best.
I have committed a patch that does this:
/(?=ab\K)/+
abcd
Start of matched string is
p...@hermes.cam.ac.uk писал(а) в своём письме Fri, 27 Dec 2013 16:28:20
+0400:
On Thu, 26 Dec 2013, Zoltán Herczeg wrote:
I didn't know it is accidental. I thought printing an empty string is
less useful for a testing tool. Perhaps printing the offsets
themselves would be the best.
I have
On Tue, 24 Dec 2013, ND wrote:
I know nothing about C debugging. I'm so sorry.
My OS is Windows 7 64 bit. If you can't reproduce this bug on Linux OS, then
may be anyone else who have Windows 7 be able to debug C programs on it...
It is clear that pcretest has a bug here. It does not
Hi,
In Linux, it just prints the rest of the string, starting at the start
position - I think this is probably accidental. When the length of the
matched string is negative, it prints to the end of the string.
Presumably in your case there isn't a trailing zero...
I didn't know it is
On 2013-12-24 08:24, Zoltán Herczeg wrote:
Did you see my other mail yesterday? I explained there that pcretest
yields 'b' for testing purposes (it handles startoffset is greater than
endoffset cases this way). I also described how this issue can be
debugged.
Yes. I see this e-mail. But
Hi,
Anyway I suspect the result is correct (it start with b)
I don't think so. Result must not have 'b'.
Did you see my other mail yesterday? I explained there that pcretest yields 'b'
for testing purposes (it handles startoffset is greater than endoffset cases
this way). I also described
On Mon, 23 Dec 2013, ND wrote:
It seems that last PCRE version have this problem too:
I have not looked at this yet, and as I have visiting family over the
holiday period, I may not get a chance till next week. Grandchildren are
fun, but hard work.
Philip
--
Philip Hazel
--
## List
Hi,
just a little help for debugging this. In such cases, where the start offset is
bigger than end offset (1 0 this case), pcretest prints out the characters
from start offset to the end of the input. It could print an empty string (such
as Perl), but that would not be helpful for
On 2013-12-23 07:11, Zoltán Herczeg wrote:
Could you try it with a newer version?
It seems that last PCRE version have this problem too:
PCRE version 8.35-RC1 2013-12-23
/(?=a\K)/
ab
0: bx\xae\xf4\xdfpZ\x04
yes it seems there is a rubbish after the 'b'. However, I don't see this
Hi,
yes it seems there is a rubbish after the 'b'. However, I don't see this
behavior in the recent release (under Linux at least), and your binary is half
year old. Could you try it with a newer version?
Anyway I suspect the result is correct (it start with b), just the printing
does not
Good day!
Here is pcretest.exe listing:
PCRE version 8.34-RC 2013-06-14
/(?=a\K)/
ab
0: b\x89b\x1f\xe4J~\x04
This match is unpredictable for me. May be a bug there.
Thanks a lot.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
13 matches
Mail list logo
