https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124882
--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #5)
> But what problem would we be solving? The false-positive middle end warning
> was fixed years ago by Aldy improving VRP. Are there other false
> -Wstringop-overread warnings that this would help? I hope those would also
> be fixed in the right place, not like this.
My intention here was to make the code more robust, but given that it comes at
a cost, I agree it's not a good trade-off.
Having said that, we could approach this from the other side, and look at
substr, and do:
...
diff --git a/libstdc++-v3/include/std/string_view
b/libstdc++-v3/include/std/string_view
index 735d46f2de7..40d2d91a353 100644
--- a/libstdc++-v3/include/std/string_view
+++ b/libstdc++-v3/include/std/string_view
@@ -339,7 +339,16 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
[[nodiscard]]
constexpr basic_string_view
- substr(size_type __pos = 0, size_type __n = npos) const noexcept(false)
+ substr(size_type __pos = 0, size_type __n =
++#if __PTRDIFF_MAX__ < __SIZE_MAX__
+ /* The standard mandates npos == (size_t)-1 here, but since this
+ is used internally only, using __PTRDIFF_MAX__ shouldn't make a
+ difference in semantics, but it could help range analysis. */
+ __PTRDIFF_MAX__
+#else
+ npos
+#endif
+ ) const noexcept(false)
{
__pos = std::__sv_check(size(), __pos, "basic_string_view::substr");
const size_type __rlen = std::min<size_t>(__n, _M_len - __pos);
...
which wouldn't come at a cost.
But yeah, I'm not sure it's worth the trouble.
