
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. John Maddock wrote:
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.