https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #6 from Giuseppe D'Angelo <dangelog at gmail dot com> --- (In reply to Martin Sebor from comment #5) > It wouldn't be right to change the wording of just one warning because the > problem applies to all flow based diagnostics. They all depend on various > optimizations that propagate constants, add or remove tests, and change the > control flow graph. A statement that in the source code is conditional on > the values of various parameters might in the intermediate representation > appear unconditional with constants as a result, even be unconditionally > invalid but unreachable. This is true at function scope as well as across > function call boundaries thanks to inlining. Changing the wording for all > of them to try to somehow reflect this wouldn't help because then all > instances of them all would have to use the new form. Sorry, why wouldn't help? That is, given the fact that these warnings do have false positives, why would it bad for such warnings to say "something bad MIGHT be happening here" vs "something bad IS happening here"? For an end user, it makes a lot of difference to know if the compiler has definitely found something wrong vs. the compiler may or may not have found it. Just a tiny language change in the printed mesage would reassure the user that the warning could, in fact, be a false positive. (Compare this to "there IS something bad here". You read the code in question, and you don't see what's bad, and you start digging around trying to understand "why is the compiler telling me that there IS something bad? Am I not seeing something?".) > -Wuninitialized and -Wmaybe-uninitialized aren't substantially different in > this. The latter is unique only in that it diagnoses arguments of PHI > nodes, which are the results of conditional expressions. This property is > described by the following sentence in the manual: > > "...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." > > This is only roughly what happens but there are many instances of > -Wuninitialized that could be described using the same sentence, even though > it doesn't consider PHI nodes. If we do introduce a similar distinction in > other warnings like -Wstringop-overflow it will be on top of the instances > already issued by them, not a subset of them. > > This is a general property of all flow based warnings in GCC except those > emitted by the static analyzer which doesn't depend on the same > optimizations (only a very small subset of them). All warnings (flow based > or otherwise, including those issued by the analyzer) should always be > viewed as documented, i.e., as "messages that report constructions that are > not inherently erroneous but that are risky or suggest there may have been > an error." "not inherently erroneous" is as per language rules (i.e. the program isn't ill-formed). But "there may have been" an error is the key I'm trying to point out. The compiler can prove that something is a mistake, or can only estimate that, and so raise a false positive. I'd rather have a message telling me whether a given warning is because of a proof or an estimate.
