https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #22 from Jonathan Wakely ---
No, comment 1 was from Richard. And the warning already exists, and it says
that a nonnull argument (i.e. something that can never be null) is compared to
null. The only thing I'd change would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Andrew Pinski changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Matthieu Brucher changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #19 from Matthieu Brucher ---
That was my original comment... Thanks for quoting me...
The issue is that the warning doesn't tell me what you told me, that "this" is
never equal to nullptr in that context. This is what the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #17 from Matthieu Brucher ---
Not everyone runs this sanitizer, and not everyone has unit tests that can find
this error (the application I woked on that had this has numerous unit tests,
but this was not tested because the guy that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #16 from Andrew Pinski ---
-fsanitize=undefined will catch the NULL pointer at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #15 from Matthieu Brucher ---
Thanks, finally something relevant, yes it's a bug that can be easilly checked
by gcc and that GCC can easilly warn about. (lowering the bar here). Yes, the
user should chase the bug because they screwep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #14 from Jonathan Wakely ---
(In reply to Matthieu Brucher from comment #11)
> Oh, and if this is always false, why isn't it the case in debug mode? It is
> then a bug according to what you said.
It is always false in a valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #13 from Jonathan Wakely ---
See comment 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Matthieu Brucher changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #11 from Matthieu Brucher ---
Oh, and if this is always false, why isn't it the case in debug mode? It is
then a bug according to what you said.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #10 from Matthieu Brucher ---
If it is always false, what impeds you for warning as such? Because numerous
people are checking this (and I agree that they shouldn't), as proven by my 2
links.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #8 from Matthieu Brucher ---
In a header:
class Foo
{
public:
void bar();
};
Inthe corresponding source:
#include
void Foo::bar()
{
if(this)
{
std::cout << "Pointer is not null";
}
else
{
std::cout << "Pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #7 from Daniel Krügler ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #6 from Matthieu Brucher ---
I never said that the test alone should be banned. Please read the original
message first.
I said that if(!this) in the context of a method gives "unexpected" behavior
(according to the standard and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #4 from Matthieu Brucher ---
I would agree if the debug and optimized versions had the same behavior. They
do not. As such there should be a huge warning about the undefined behavior.
And no, it's not valid code, it's an undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #3 from Jonathan Wakely ---
(In reply to Matthieu Brucher from comment #2)
> Comparing this to anything from Null to nullptr should be an error, not be
> silently passed.
No, it can't be rejected, because it's valid code. Just like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
--- Comment #2 from Matthieu Brucher ---
No, I think the optimization is more than correct.
The warning doesn't warn of the actual problem, if you check against nullptr,
you won't even get a warning.
Comparing this to anything from Null to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81928
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
23 matches
Mail list logo
