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
prev 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: 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).