https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #7 from Daniel Krügler <daniel.kruegler at googlemail dot com> --- (In reply to Matthieu Brucher from comment #6) > I never said that the test alone should be banned. Please read the original > message first. I had done so before I replied. And it seems that I'm not the only one who has problems understanding your request. > I said that if(!this) in the context of a method gives "unexpected" behavior > (according to the standard and the difference in behavior of GCC between > debug and optimized mode) and thus should give an error or at least a > warning, and this is easy to catch. I don't understand this. Please provide an example. > At least make it a warning, like clang does when it detects that a path is > always true or false, some kind of way for the user to _know_ that they > messed up. I already suggested the same thing: The only reason to request a warning in this case is because the test result has only one outcome. But this is absolutely unrelated to undefined behaviour unless you clarify what precisely your mean. > And yes, there is something fundamentally wrong with comparing this to > nullptr according to the C++ standard and the contract GCC has in its > optimizer. You claim this repeatedly but I'm missing a proof for the "fundamentally wrong" part. Except if you consider tautologies as "fundamentally wrong". > Or give a reason why it is valid and where the standard says it > supercedes the undefined behavior and the thread discussion on why GCC added > the optimization constraint. > And in that case, you should probably remove the optimization as well to be > consistent. This part is unclear without a specific example that you are talking about, see above.
