https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534
--- Comment #3 from Mathias Stearn <redbeard0531 at gmail dot com> --- One slightly confusing aspect is that the wording of the flag implies that the variable may or may not be uninitialzied (because in -Wmaybe-uninitialized maybe binds directly to uninitialized), while phrasing of the warning message is about the usage being conditional: "may be used uninitialized". And of course the documentation (at least the man page) uses a different phrasing: > For an object with automatic or allocated storage duration, if there exists a > path from the function entry to a use of the object that is initialized, but > there exist some other paths for which the object is not initialized, the > compiler emits a warning if it cannot prove the uninitialized paths are not > executed at run time. For both the initial example with count, and your example with count2, I'd say that the "there exists a path from the function entry to a use of the object that is initialized" bit is clearly not satisfied, so if we assume the documentation is correct, then those cases both lack a "maybe" and the variables are clearly uninitialized. This would also match my intuition for -Winitialized which is that it definitively errors if all paths from declaration to any usage result in the variable being uninitialized. PS - This test case is a reduced example from an actual bug that luckily was found by coverity before release: https://jira.mongodb.org/browse/SERVER-66306. I dug in to make a repro because I was expecting that we would have gotten a compiler error on that code before it was even committed. I'm also exploring whether we can stop passing -Wno-maybe-uninitialized, but it looks like we still get false positives in third-party headers, so it doesn't seem likely.
