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

  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: 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).