public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dangelog at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow Date: Thu, 24 Jun 2021 14:07:38 +0000 [thread overview] Message-ID: <bug-101134-4-w1xB46ZjIK@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-101134-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 --- Comment #8 from Giuseppe D'Angelo <dangelog at gmail dot com> --- In a -Wall build, it's a bit unfair to pretend the users to know if a warning is being generated by the frontend, the middleend, the backend and so on. All they get is a list of warnings saying "this is like this, this is like that". You're saying that all such warnings should be treated as "maybe", as false positives are a possibility. But I don't agree with this. First, as I said, the mood of the warning is "indicative", which denotes certainty and reality, not possibility. (But I'll grant, not being a native English speaker, this may just be a personal impression of the warning being "stern".) Second, the presence of things like -Wmaybe-uninitialized vs -Wuninitialized hints at the fact that GCC *wants* to distinguish these "maybe" vs. "certain" cases, at least in certain contexts (like, where it CAN do that!), and give different warnings if it can. Third, frontend warnings simply don't have false positives: if the compiler tells you "this function may be marked override", "this class has virtual functions but no virtual destructor", "this case label falls through into the next one", that's absolutely true in 100% of the cases. A false positive here would clearly be treated as a bug in GCC, and not dismissed as "but it's a warning, and a warning is just a 'maybe', and yes, GCC is telling you to add `override`, and then you added it, and now the program doesn't even build any more because the warning was wrong and `override` was not even needed, but see, it's your fault for not understanding the 'maybe' part". So, in a nutshell, yes, I'd be much more comfortable if warnings that denote a possibility (for any reason, really, I'm not asking to NEVER generate false positives) would simply have "may" or "might" added to their text. If that's the majority of middle-end warnings because they all generate false positives, why would that be a problem, in principle? But fair enough, let's agree to disagree. :)
next prev parent reply other threads:[~2021-06-24 14:07 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-19 9:52 [Bug middle-end/101134] New: " dangelog at gmail dot com 2021-06-21 16:10 ` [Bug middle-end/101134] " msebor at gcc dot gnu.org 2021-06-21 16:44 ` dangelog at gmail dot com 2021-06-21 20:40 ` msebor at gcc dot gnu.org 2021-06-22 8:57 ` dangelog at gmail dot com 2021-06-22 15:27 ` msebor at gcc dot gnu.org 2021-06-22 16:34 ` dangelog at gmail dot com 2021-06-23 19:56 ` msebor at gcc dot gnu.org 2021-06-24 14:07 ` dangelog at gmail dot com [this message] 2021-06-24 17:05 ` segher at gcc dot gnu.org 2021-06-24 17:57 ` rsandifo at gcc dot gnu.org 2021-06-24 19:36 ` dmalcolm at gcc dot gnu.org 2021-06-24 21:18 ` msebor at gcc dot gnu.org 2021-06-24 22:18 ` dangelog at gmail dot com 2022-03-17 10:18 ` redi at gcc dot gnu.org
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-101134-4-w1xB46ZjIK@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).