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 middle-end/94815] Abusive -Wrestrict warning with sprintf
Date: Tue, 28 Apr 2020 16:58:46 +0000	[thread overview]
Message-ID: <bug-94815-4-PdTxpMFECX@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94815-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94815

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
           Keywords|                            |missed-optimization
             Blocks|                            |83819
             Status|REOPENED                    |RESOLVED
          Component|c                           |middle-end

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
The test case in comment #4 isn't handled yet.  Even though the sprintf code
has access to the results of the strlen pass computed for prior string built-in
function calls and so knows the length of str3, it doesn't expose the lengths
of the strings it itself computes to the strlen pass (or track them across
statements) yet so it doesn't "know" the length of str2 computed at the prior
sprintf statement.

When the sprintf pass makes use of attribute alloc_size it will be able to use
the array sizes to improve its analysis but as I mentioned in comment #2 this
isn't implemented yet either.  The effect that we will get once it is can be
emulated by replacing buf with a fixed size array (char buf[30]).  It doesn't
eliminate the warning due to the missing bits above but the output of the
-fdump-tree-strlen option confirms that the warning is due to the strlen
limitation:

pr94815.c:15: sprintf: objsize = 20, fmtstr = "ABC%s"
  Directive 1 at offset 0: "ABC", length = 3
    Result: 3, 3, 3, 3 (3, 3, 3, 3)
  Directive 2 at offset 3: "%s"
    Result: 3, 3, 3, 3 (6, 6, 6, 6)
  Directive 3 at offset 5: "", length = 1
  Substituting 6 for return value.

pr94815.c:18: sprintf: objsize = 30, fmtstr = "DEF%s"
  Directive 1 at offset 0: "DEF", length = 3
    Result: 3, 3, 3, 3 (3, 3, 3, 3)
  Directive 2 at offset 3: "%s"
    Result: 0, 19, 19, 19 (3, 22, 22, 22)   <<< str2 length assumed to be up to
19
  Directive 3 at offset 5: "", length = 1

PR 92813 tracks the enhancement to make the string length information computed
by sprintf across statements (via the strlen pass).

*** This bug has been marked as a duplicate of bug 92813 ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

      parent reply	other threads:[~2020-04-28 16:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 11:56 [Bug c/94815] New: " vincent.riviere at freesbee dot fr
2020-04-28 13:33 ` [Bug c/94815] " rguenth at gcc dot gnu.org
2020-04-28 14:18 ` msebor at gcc dot gnu.org
2020-04-28 14:33 ` msebor at gcc dot gnu.org
2020-04-28 15:02 ` vincent.riviere at freesbee dot fr
2020-04-28 16:58 ` msebor at gcc dot gnu.org [this message]

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-94815-4-PdTxpMFECX@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).