[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Your program's invalid for other reasons too, you can't mix strdup and delete.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #8 from aral at gmx dot de --- I agree that updating the documentation exceeds the responsibility of this bug reporting system, and if the behavior is intended, it is not a bug. The severity was referring to the case had the behavior been unintended. So - who is behind cppreference.com if it is not an official reference? And cpluscplus.com?
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 Sergey Zubkov cubbi at cubbi dot org changed: What|Removed |Added CC||cubbi at cubbi dot org --- Comment #9 from Sergey Zubkov cubbi at cubbi dot org --- Just a few volunteers, aral. You can bring up your concerns and suggestions on the Discussion tab of any cppreference.com page and on the Spotted an error? contact us at the bottom of any cplusplus.com/reference page.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Severity|major |normal --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- There's no GCC bug here, closing.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #1 from aral at gmx dot de --- AFAICT the same bug is applicable to the regex_match function. Sorry for the copy paste error in the very last comment.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to aral from comment #3) I don't argue that it might be a misunderstanding of the user, hence my suggestion 1) - however, I disagree with your wording clearly documented as far as (a) http://en.cppreference.com/w/cpp/regex/regex_search and (b) http://www.cplusplus.com/reference/regex/regex_search/ are concerned. I could not find any clear statement on c++ official language reference with a google search. Is (a) official? No, neither (a) nor (b) are official C++ Standard specifications. A relevant one would be ISO/IEC 14882:2011 for C++11 for example. The Standard itself is no text book, so your definition of clarity does need to be reflected by that. See e.g. the link provided on https://isocpp.org/std/the-standard to retrieve it or as an approximation to the official document refer to the current working *draft* that can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf But all this exceeds the responsibility for this bug tracking system. You could probably request an enhancement of the libstdc++ documentation, but I believe that a priority of P3 major is not an appropriate one for this.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #3 from aral at gmx dot de --- I don't argue that it might be a misunderstanding of the user, hence my suggestion 1) - however, I disagree with your wording clearly documented as far as (a) http://en.cppreference.com/w/cpp/regex/regex_search and (b) http://www.cplusplus.com/reference/regex/regex_search/ are concerned. I could not find any clear statement on c++ official language reference with a google search. Is (a) official? Either way, (a) states 7) The overload 3 is prohibited from accepting temporary strings, otherwise this function populates match_results m with string iterators that become invalid immediately. I do not find this very clear, especially since 7) is denoted since C++14, and the temporary strings are already a problem in C++11. How about a statement like this for 2), 3), 5) and 6)? And maybe a clearer wording? I find the abscence of such a warning, along with the const statement in the parameter declaration (indicating one could submit a string literal for const charT* s) misleading to say the least.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #4 from aral at gmx dot de --- Addition: after you referred to the properties of match_results, I had a look at http://en.cppreference.com/w/cpp/regex/match_results which has a clearer wording. However, I still think this clear statement = it's undefined behavior to examine std::match_results if the original character sequence was destroyed or iterators to it were invalidated for other reasons should be added to the description of the functions that populate the match_results. The user (I, in this case) does not always check the descriptions of every single function parameter if the function description seems to give all the information needed to use it. What could be improved (to avoid bugs going undetected) is to raise an exception if the match_results are accessed after the haystack has been destroyed.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- The behaviour is intended and clearly documented by the specification of the Standard Library: match_results, such as cmath, just hold weak references (via its sub_match elements) to the original search sequence, so (2) is definitively not an option. This doesn't look like a defect to me, this is just a misunderstanding of the user about the semantics of std::regex_search.
