public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "carlosgalvezp at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
Date: Sun, 11 Sep 2022 08:31:37 +0000	[thread overview]
Message-ID: <bug-106901-4-bFq7Iu60T3@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106901-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
I also would like to understand why the warning is not triggered if the first
"if (size < expected_size)" is removed. 

https://godbolt.org/z/7vqPxhsqo

The possibility of executing the loop and do out-of-bounds still exists, right?
So why is the compiler warning in one case and not other?

Similarly, a regular for-loop with "size" known at runtime is equally risky,
yet the compiler is not flagging it:

bool bar(std::array<int, 5> const& vec,
         std::size_t const size)
{
    for (std::size_t i{0}; i < size; ++i)
    {
        if (vec[i] != 0)
        {
            return false;
        }
    }
    return true;
}

https://godbolt.org/z/6c64MEY7d

Personally, I think this warning should only warn about 100% confirmed OOB
cases, and put the "maybe" cases in a separate flag. All respectable projects
have as minimum "-Wall -Werror" in their compiler flags, to detect problems
that do exist, not that "might" exist. This can lead to quite a few false
positives, leading to people either disabling the warning altogether (which is
pretty bad!) or polluting the code with inline pragmas (disallowed by some
coding guidelines).

  parent reply	other threads:[~2022-09-11  8:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-10 17:06 [Bug c++/106901] New: " carlosgalvezp at gmail dot com
2022-09-10 17:15 ` [Bug c++/106901] " pinskia at gcc dot gnu.org
2022-09-10 17:28 ` carlosgalvezp at gmail dot com
2022-09-10 17:32 ` pinskia at gcc dot gnu.org
2022-09-10 18:27 ` carlosgalvezp at gmail dot com
2022-09-11  8:31 ` carlosgalvezp at gmail dot com [this message]
2022-09-12  7:57 ` [Bug tree-optimization/106901] [13 Regression] " rguenth at gcc dot gnu.org
2022-10-11 12:28 ` carlosgalvezp at gmail dot com

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-106901-4-bFq7Iu60T3@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).