On Tue, Feb 01, 2022 at 04:54:17PM -0700, Martin Sebor wrote: > On 1/31/22 22:18, Richard Sandiford wrote: > >I agree that changing the wording doesn't solve the whole problem, > >but I think it does solve something. At the moment, we're effectively > >asking each individual user to be aware of the context above, to know what > >meaning is being attached to the present tense. Making the message more > >equivocal would at least suggest that the compiler doesn't “know”. > > The compiler can never "know" for certain if any statement will be > executed. It can when it sees the whole source code. Since noreturn attributes are not required for functions that do not return, you can not tell otherwise, sure. For warnings you can assume any function that does not say it does not not return does return, but yes you cannot know. > Every warning message that involves control or data flow > must be interpreted in the context of the surrounding code, whether > it's an expression, statement, or the whole function. Of course. But if a warning message says "your code is wrong", it is a bit of a leap to read that as "your code might be wrong", or "it looks suspicious", etc. > Every warning > message must necessarily also be understood as only suggesting that > "there may be a problem" in the program rather than "there definitely > is a bug." But that is for a very different reason: every warning also has false positives. If not, it should be an error, not a warning! > There's plenty of literature out there that explains this, including > the GCC manual, so I'd expect most C/C++ programmers to understand > that. But if your warning message says "your code is wrong", you cannot blame the user for understanding that exactly as written. > I don't think that rewording every warning message just to > drill that message home and without addressing the bigger problem > would make enough of a difference to justify the effort. Our diagnostic messages should not lie. This is definitely worth the effort. Yes, it can be hard, but the whole *goal* is to help the user, so it makes sense to put in some effort to do help the user, instead of frustrating him/her. > (Users > don't feel any better about -Wmaybe-uninitialized false positives > than about -Wuninitalized, and they've periodically argued to > remove the former from -Wall despite its equivocal phrasing.) Of course they are not happy to see a messsage like "this or that may be used uninitialised", but in what world does that make it okay for the compiler to see "thhis *is* used uninitialised"? That makes no sense. > I agree. I think there are at least two underlying problems: users > expecting every warning message to point out an actual bug in their > code, You make that problem worse by telling the user that his code is wrong (instead of saying it loooks suspicious, it may be wrong). > and GCC failing to somehow indicate the conditional nature of > the problems in the messages. Yes. We should have a way to say "this is UB if it ever is executed". And we do have one such way: we insert an abort before the statement. Which we do not do here. If we want to not do this (the aborts are kind of unfriendly after all), it would be nice to have a helper warning message function warning_if_executed or similar, that would take care of the phrasing and make it consistently correct for all such warnings. Segher
