Boost.Regex 1.39.0: Crash in boost::sub_match::str()

The program below crashes when compiled and executed in Windows using MSVC8.
The crash happens in boost::sub_match::str(). It seems that the internal structure m_subs gets somehow corrupted.
The crash disappears when passing the const reference fileName instead of it->path().filename(). I have no idea why this should make any difference.
The program expects a directory on the command line. Just put an empty file called "AAA-0.txt" in this directory.
Any help is appreciated.
Regards, Peter.
#include <iostream>
#include

Peter Klotz wrote:
The program below crashes when compiled and executed in Windows using MSVC8.
The crash happens in boost::sub_match::str(). It seems that the internal structure m_subs gets somehow corrupted.
The crash disappears when passing the const reference fileName instead of it->path().filename(). I have no idea why this should make any difference.
Regex does not keep a copy of the string, but instead uses the passed in string. The result of the filename method is going out of scope immediately after the regex_match call, and the memory in match.str() is invalid. Binding the temporary to a const reference keeps the string valid through the iteration of the loop. See https://svn.boost.org/trac/boost/ticket/1749 and http://herbsutter.wordpress.com/2008/01/01/gotw-88-a-candidate-for-the-most-... -- Anthony Foglia Princeton Consultants (609) 987-8787 x233

Hello Anthony
Regex does not keep a copy of the string, but instead uses the passed in string. The result of the filename method is going out of scope immediately after the regex_match call, and the memory in match.str() is invalid.
Thanks a lot. I did not realize that the iterators have to survive the call but it is obvious now. Regards, Peter.
participants (3)
-
Anthony Foglia
-
Peter Klotz
-
Peter Klotz