From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BC0343858C54; Thu, 14 Apr 2022 11:37:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BC0343858C54 From: "avarab at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/105273] -Wanalyzer-use-of-uninitialized-value warns on "missing" default for switch when callers can be statically determined Date: Thu, 14 Apr 2022 11:37:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: analyzer X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: avarab at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2022 11:37:24 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105273 --- Comment #2 from =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason --- ...To finish the report (Bugzilla's eager submitting threw me for a loop) t= he issue is that while the analyzer is right in the *general* case about a "switch" with a missing "default" being something that *could* be fed any arbitrary value, in this case all of the possible values can be determined = at a compile-time. Which is all this bug report is suggesting as an initial report, that it wo= uld be nice to have that narrow case handled. END OF NARROW REPORT More generally though (and perhaps I should submit another report for this) it's a really useful feature of GCC (and clang) that with C they put a bit = of trust in the programmer with -Wswitch (which is enabled under -Wall). Because even though there are cases where the programmer is wrong and exhaustively enumerating the enum labels isn't sufficient, in the general c= ase being able to avoid "default" cases in favor of exhaustively listing the la= bels avoids a *lot* of subtle bugs in larger codebases. That's because the values being thrown around to "switch" on are validated already by [insert magic here], but whenever *new* values are added it's re= ally important to not miss 1/N switch statements that new labels need to be added to. In the testcase for this bug the compiler has enough visibility to determine this to be true without the "[insert magic here]", but in cases where that's not true it seems to me that those users -fanalyzer would be encouraged to = add "default" cases just to appease the compiler, and thus get worse warnings f= rom -Wswitch. I may be missing something obvious, but it would be nice to have some way o= ut of that where you can have your cake & eat it too. I.e. only have -fanalyze complain about this class of issue where -Wswitch would complain, and have = the current behavior in GCC 12.0 hidden behind some opt-in sub-flag of -Wanalyzer-use-of-uninitialized-value. Anyway, just my 0.02. Thanks a lot for -fanalyze, I've been trying it out on the git codebase and it's uncovered a lot of genuine issues already. I'm ju= st filing some bugs for the long tail where the analyzer seemed to be wrong/lacking. Thanks!=