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