Bruno.Voigt@ic3s.de wrote:
Hi all, I have a problem with an application build with the current debian/etch libboost-regex lib. I am not sure if the problem results from an intended behaviour change of the regex lib or if its a bug of either the regex lib or the debian package.
The following test app worked flawlessly with several older boost regex versions and I would like to understand why it doesn't work anymore using the lib from debian/etch.
Do I have to adjust the invocation parameters of boost_merge for the current version?
I do not unnecessarily want to force the users of my production apps to have to update their match patterns over dozens of cfg files from "(.*)" to "^(.*)$".
TIA for any hints,
I'm not sure you're going to like the answer: this is a deliberate change and a bug fix to make the library do the same thing as Perl etc. When matching "(.*)" against "abc" there are *two* matches found: one matches "abc" then a second match is possible against the zero-length-string at the end of the text. You can prevent matching null-strings altogether by passing match_not_null to regex_merge: boost::regex_merge(my_string, my_regex_comp, my_replace, boost::regex_constants::match_not_null); But that prevents all zero-length matches, which your users might not appreciate either :-( I can't think of an easy way to emulate the previous buggy behaviour I'm afraid. Regards, John.