John Maddock wrote:
Ø You
shouldn't get that exception from that expression: that exception is
raised when the number of states visted in the search for a match looks to
be growing exponentially, it's usually caused by "pathological"
regular
expressions like "(.*)*" that can end up searching forever on some
inputs.
Do you have a more specific test case please?
John.
Ø
Hi John.
Thanks for quick reply. I’m
afraid I don’t have more specific test. Maybe additional info will help.
Boost v.1.33.1, VC 8.0.
The buffer content looks like:
00:00:00.000 [category
100] EXCEPTION: test log-message #100
00:00:00.000 [category 101] ERROR: test log-message #101
new line
00:00:00.000 [category 102] WARNING: test log-message #102
00:00:00.000 [category 103] INFO: test log-message #103
00:00:00.000 [category 104] DEBUG: test log-message #104
00:00:00.000 [category 105] EXCEPTION: test log-message #105
new line
00:00:00.000 [category 106] ERROR: test log-message #106
[...]
00:00:00.000 [category
300] EXCEPTION: test log-message #300
As result, threre's no match for "#1.*#7" in
such content. Debugger shows that regex_search reached position
"171\r\n00:00:00.000 [category 172] WARNING: test log-message #172[...]",
state_count = 468663, max_state_count = 468640.
Can I provide any additional useful info? Should I send you standalone test for problem reproduction?
Thank you,
Andriy.
> Andriy Tylychko (mail.ru) wrote:
>> Hi,
>>
>> The code looks like:
>>
>> std::string buffer(10240, '\0');
>> // ... fill buffer
>> boost::regex e("#1.*#7");
>> boost::smatch m;
>> boost::regex_search(buffer, m, e);
>>
>> The buffer of 10KB is full of "something #x". As result I
receive
>> regex_constants::error_space at
>> boost\regex\v4\perl_matcher_non_recursive.hpp:164.
>> I'll highly appreciate any help.
>
> You shouldn't get that exception from that expression: that exception is
> raised when the number of states visted in the search for a match looks to
> be growing exponentially, it's usually caused by "pathological"
regular
> expressions like "(.*)*" that can end up searching forever on
some inputs.
>
> Do you have a more specific test case please?
>
> John.