[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #43 from Jonathan Wakely --- And updating vstring is exactly what I'd like to avoid. It's pretty much on life support as far as I'm concerned.
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #42 from Randy --- (In reply to Jonathan Wakely from comment #41) > So then basically the same as what I said: > > (In reply to Jonathan Wakely from comment #37) > > (Your segfaults are probably because you're using c_str() on a temporary > > string, so accessing the pointer after the temporary goes out of scope.) > > You're relying on the string contents outliving a specific object, which > only works if the contents are reference-counted and there is still another > object somewhere that owns it. Your code has a bug. This isn't the place to discuss this. vstring solved the problem I was having at the time and I don't know if its still an issue. Might have been using gcc-4.8.x at the time and I think std::string implementation changed since then. I have no reason to switch from using vstring, I just want those who work on gcc to also consider updating vstring with the same type of fixes for this warning.
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #41 from Jonathan Wakely --- So then basically the same as what I said: (In reply to Jonathan Wakely from comment #37) > (Your segfaults are probably because you're using c_str() on a temporary > string, so accessing the pointer after the temporary goes out of scope.) You're relying on the string contents outliving a specific object, which only works if the contents are reference-counted and there is still another object somewhere that owns it. Your code has a bug.
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #40 from Randy --- (In reply to Jonathan Wakely from comment #39) > (In reply to Randy from comment #38) > > std::string is not thread safe, this is why vstring is used (from my > > memory). > > That's totally wrong, vstring has no more thread-safety than std::string > has. The same rules apply to both of them (it's OK to call const member > functions concurrently, but any non-const access must be manually > synchronized by the caller). I googled, I think I rember now, its due to reference counting. I would get cases where its deallocating something internally due to the way I pass strings around to my threads.
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #39 from Jonathan Wakely --- (In reply to Randy from comment #38) > std::string is not thread safe, this is why vstring is used (from my > memory). That's totally wrong, vstring has no more thread-safety than std::string has. The same rules apply to both of them (it's OK to call const member functions concurrently, but any non-const access must be manually synchronized by the caller).
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #38 from Randy --- (In reply to Jonathan Wakely from comment #37) > Please report a separate bug for vstring then. > > (Your segfaults are probably because you're using c_str() on a temporary > string, so accessing the pointer after the temporary goes out of scope.) std::string is not thread safe, this is why vstring is used (from my memory). I don't use c_str out of scope. I lost the documentation that exclaimed why to use vstring instead of std string to me. At the time, vstring solved all of our segaults in the internals of the string. Exactly why this is the case I don't remember or even if its still an issue in newer gcc versions. The bug with the warning in this thread exists in vstring as well. I will look at filing a separate bug report then... In static member function âstatic constexpr std::char_traits::char_type* std::char_traits::copy(std::char_traits::char_type*, const char_type*, std::size_t)â, inlined from âstatic void __gnu_cxx::__vstring_utility<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, __gnu_cxx::__vstring_utility<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]â at /usr/include/c++/11/ext/vstring_util.h:112:21, inlined from â__gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>& __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::_M_replace(__gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type, __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type, const _CharT*, __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator; _Base = __gnu_cxx::__sso_string_base]â at /usr/include/c++/11/ext/vstring.tcc:160:20, inlined from â__gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>& __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::replace(__gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type, __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type, const _CharT*, __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator; _Base = __gnu_cxx::__sso_string_base]â at /usr/include/c++/11/ext/vstring.h:1313:19, inlined from â__gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>& __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::insert(__gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type, const _CharT*, __gnu_cxx::__versa_string<_CharT, _Traits, _Alloc, _Base>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator; _Base = __gnu_cxx::__sso_string_base]â at /usr/include/c++/11/ext/vstring.h:1085:29, inlined from âBouncedConnection::ReturnAction BouncedConnection::Handle_Notify(rapidjson::Document&, FullThreadCommandLogInstance&, String&)â at BouncedConnectionCmdProcessing.cpp:2258:54: /usr/include/c++/11/bits/char_traits.h:409:56: warning: âvoid* __builtin_memcpy(void*, const void*, long unsigned int)â reading 2 bytes from a region of size 1 [-Wstringop-overread] 409 | return static_cast(__builtin_memcpy(__s1, __s2, __n)); | ^
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #37 from Jonathan Wakely --- Please report a separate bug for vstring then. (Your segfaults are probably because you're using c_str() on a temporary string, so accessing the pointer after the temporary goes out of scope.)
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #36 from Randy --- (In reply to Jonathan Wakely from comment #35) > As you can see from the commit above, nothing was changed in > __gnu_cxx::vstring (there is no "std_vstring"). Ok then can someone look at __gnu_cxx::vstring, we use this instead as std::string causes segfaults in our code. I'm getting the error as described here but using __gnu_cxx::vstring in gcc-11, and if it can be fixed or is fixed? in newer gcc versions then I can go through the process of upgrading.
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 --- Comment #35 from Jonathan Wakely --- As you can see from the commit above, nothing was changed in __gnu_cxx::vstring (there is no "std_vstring").
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Randy changed: What|Removed |Added CC||Randy at miningrigrentals dot com --- Comment #34 from Randy --- Is the patch for GCC 12 for this issue also applied to std_vstring?
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Known to fail|11.0| Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #33 from Martin Sebor --- With the workaround in r11-7146 the warning should no longer be issued for std::string::insert. Thanks to r12-2087 suppression by #pragma GCC diagnostic works reliably even with inlining in GCC 12, so the warning can also be suppressed using it. I'm not working on any other improvements related to the underlying problem but I think this report can be resolved as fixed in GCC 11 and 12.
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Martin Sebor changed: What|Removed |Added Target Milestone|11.0|12.0 --- Comment #32 from Martin Sebor --- The solution in https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html has been deferred to GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565551.html
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Jakub Jelinek changed: What|Removed |Added Summary|[11 Regression] Bogus |Bogus -Wstringop-overread |-Wstringop-overread with|with -std=gnu++20 -O2 and |-std=gnu++20 -O2 and|std::string::insert |std::string::insert | --- Comment #31 from Jakub Jelinek --- Workaround applied, keeping open for improving _M_disjunct in GCC 12.
