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
next 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