Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/build] Reimplement Wstringop-overread workaround
Date: Tue, 14 Apr 2026 15:48:21 +0200	[thread overview]
Message-ID: <20260414134821.2638550-1-tdevries@suse.de> (raw)

While working on commit 391c4026573 ("[gdb] Simplify debuginfod_is_enabled") I
noticed this Wstringop-overread workaround:
...
      url_view = url_view.substr (off);
      /* g++ 11.2.1 on s390x, g++ 11.3.1 on ppc64le and g++ 11 on
	 hppa seem convinced url_view might be of SIZE_MAX length.
	 And so complains because the length of an array can only
	 be PTRDIFF_MAX.  */
      DIAGNOSTIC_PUSH
      DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
      off = url_view.find_first_of (' ');
      DIAGNOSTIC_POP
...

I had difficulty understanding how the warning got triggered, and why it was
ok to ignore it, so I investigated this and ended up filing a gcc PR [1].

While doing so, I realized that this:
...
-      url_view = url_view.substr (off);
+      url_view = url_view.substr (off, PTRDIFF_MAX);
...
is a simpler workaround, that:
- is not specific to the warning and also
- states explicitly what the assumption is we're making.

I ended up using this instead to make the workaround part more minimal:
...
       url_view = url_view.substr (off);
+#if defined (__GNUC__) && !defined (__clang__)
+      url_view = url_view.substr (0, PTRDIFF_MAX);
+#endif
       off = url_view.find_first_of (' ');
...

The gcc PR got closed (because there's no known reproducer with gcc 12 and
later), but I use the workaround without version limit, because there's no
actual proof that the problem is fixed.

Tested on x86_64-linux.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124879
---
 gdb/debuginfod-support.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/gdb/debuginfod-support.c b/gdb/debuginfod-support.c
index 40b816c5a40..b5e790c3b95 100644
--- a/gdb/debuginfod-support.c
+++ b/gdb/debuginfod-support.c
@@ -249,14 +249,15 @@ debuginfod_is_enabled ()
       if (off == std::string_view::npos)
 	break;
       url_view = url_view.substr (off);
-      /* g++ 11.2.1 on s390x, g++ 11.3.1 on ppc64le and g++ 11 on
-	 hppa seem convinced url_view might be of SIZE_MAX length.
-	 And so complains because the length of an array can only
-	 be PTRDIFF_MAX.  */
-      DIAGNOSTIC_PUSH
-      DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
+#if defined (__GNUC__) && !defined (__clang__)
+      /* With g++ 11, we encounter a Wstringop-overread in
+	 url_view.find_first_of.  G++ seems convinced url_view might be of
+	 SIZE_MAX length here.  And so complains because the length of an
+	 array can only be PTRDIFF_MAX.  Work around this by explicitly
+	 limiting the size of url_view to PTRDIFF_MAX.  See PR gcc/124879.  */
+      url_view = url_view.substr (0, PTRDIFF_MAX);
+#endif
       off = url_view.find_first_of (' ');
-      DIAGNOSTIC_POP
       gdb_printf
 	(_("  <%ps>\n"),
 	 styled_string (file_name_style.style (),

base-commit: 391c4026573aeb1e6e09f36816901f2ade537e1a
-- 
2.51.0


             reply	other threads:[~2026-04-14 13:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 13:48 Tom de Vries [this message]
2026-04-14 17:38 ` Tom Tromey
2026-04-16 10:58   ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260414134821.2638550-1-tdevries@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox