public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103173] strncpy output may be truncated copying 32 bytes from a string of length 1439 (bogus) [-Werror=stringop-truncation] Date: Wed, 10 Nov 2021 19:17:43 +0000 [thread overview] Message-ID: <bug-103173-4-YFGjuIY9pE@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103173-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103173 Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed| |2021-11-10 Keywords| |diagnostic Blocks| |88781 --- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- Confirmed. The warning here is the result of the limits of the representation GCC uses for the source argument. The warning sees the following IL: strncpy (&dest, &MEM <char[32]> [(void *)&data], 32); and uses the size of data as the upper bound on the length of the string stored in it. That obviously doesn't correspond to the source code which is more closely represented by this IL: j = 0; _1 = &data[j].name; strncpy (&dest, _1, 32); But as the IL changes from the original representation above to the &MEM thing to make it easier for optimizers to work with, it loses that important detail and causes the false positive. The "fix" is to either try to undo the IL change and reconstruct the original (which is never going to be perfect) or to run the warnings on the IL before it loses the important detail. The latter will mean that the warning will not benefit from some of the optimizing transformations that depend on the MEM representation. All solutions involve trade-offs between false positives and false negatives. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 [Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings
next prev parent reply other threads:[~2021-11-10 19:17 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-10 15:40 [Bug tree-optimization/103173] New: " patrickdepinguin at gmail dot com 2021-11-10 19:17 ` msebor at gcc dot gnu.org [this message] 2021-11-11 9:15 ` [Bug tree-optimization/103173] " rguenth at gcc dot gnu.org 2021-12-21 15:26 ` patrickdepinguin at gmail dot com 2021-12-21 15:35 ` patrickdepinguin at gmail dot com 2023-07-20 8:48 ` georgmueller at gmx dot net
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=bug-103173-4-YFGjuIY9pE@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).