[pcre-dev] [Bug 2290] Recursion issue

Pàgina inicial
Delete this message
Autor: admin
Data:  
A: pcre-dev
Assumpte: [pcre-dev] [Bug 2290] Recursion issue
https://bugs.exim.org/show_bug.cgi?id=2290

--- Comment #3 from smx <vsmetnjak@???> ---
No, backslashes are ok, that's why i mentioned "use single '\' if copying down
pattern", because using this in code and showing it with some dialogBox will
show one slash - as expected(depends if one is using some kind of 'string'
class that interpretes this automatically), while using any UserMode program
doesn't need that two back slashes - only one. This is just an escape sequence
to be used later by re. It's the same as if one passes on windows
MessageBox(NULL,"sla\\sh","someTitle",0); -> sla\sh will be displayed, same
thing on linux. If you use only \( in c/c++ code, '(' would be used in re.

So this is not the case, but if it works on your tests with the same version,
then it should also work here, because they seem to be exact version 8.42 and
PCRE_DATE           2018-03-20.
The code i use is some thin c++ wrapper, it was used for quite some years, but
recursion was never used in it.
What this thin wrapper is using, boils down to example like this - taken
directly from the debugger:
std::string patt="\\(([^()]++|(?R))*\\)";
1)
cpattern=pcre_compile2(patt.c_str(),0,&error_code,&error_string,&error_offset,NULL);
2) pcre_exec(cpattern,NULL,"(abc)",5,0,0,offsets,96)
It return -5


That question - just to make sure - does 96 here means: 96/3 which is max 32
capturedExpressions?
Or is formula for this maybe: 2(whichIsFirstTwo)+2*maxCapturedExpr?
Also, by that maxOnStackIndexes i meant REC_STACK_SAVE_MAX in 'pcre_exec.c'.

Hmm, pcre1(8.xx) or newer(10.xx) - which is faster and/or smaller?
I read somewhere that Pcre 10.xx is missing one feature that 8.xx series has,
but i don't remember what that is(callouts or maybe something else).
I also tried to write simple regexp matching stuff from scratch, but this thing
with regexp is usually quite complicated.

This then should work if it works on a pcretest, i'll try to play with pcretest
and find the cause, maybe that wrapper just doesn't use something right or
overrides something - but all other cases works fine and i checked it a few
times, any idea why this may not work is welcome.

Also, does maybe PCRE_NO_UTF8_CHECK(with PCRE_UTF8) speed things a little when
it's known for sure utf8 is used?

--
You are receiving this mail because:
You are on the CC list for the bug.