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

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