On 19/02/16 08:50 +0100, Jakub Jelinek wrote:
On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:
Jakub Jelinek wrote:
> ASSERT(this) is pointless, it is testing if undefined behavior didn't
> happen after the fact, that is just too late. As I said, use
> -fsanitize=undefined to make sure you don't call methods on nullptr.
Doesn't -fno-delete-null-pointer-checks make such ASSERTs work (and also
explicit "if (this)" type checks)? I read that that flag fixes programs
which rely on "if (this)" checks.
That switch allows to work around buggy programs, at the cost of optimizing
them less, yes. In any case, such programs should be fixed, this must be
always non-NULL, methods can't be called on NULL pointers.
Right, using -fno-delete-null-pointer-checks doesn't "fix" the
programs, they still have undefined behaviour.
Checking "if (this)" is completely brain-damaged. If you want to ask
questions like "do I exist?" then practise philosophy not C++.
The other common problem uncovered by the new optimization is in code
like:
foo()->bar();
where foo() happens to return a null pointer. If bar() doesn't access
any members of *this then previously this compiled and ran without
error. This code isn't brain-damaged, it's just got a bug, and should
have checked for null if that is a possible result of foo() e.g.
if (auto p = foo())
p->bar();
else
/* do something appropriate */;
Using -fno-delete-null-pointer-checks will make the code appear to
work correctly again, but obviously it's still wrong if foo() can
return a null pointer. And if bar() was ever changed to access a
member of *this then it would start crashing, even with
-fno-delete-null-pointer-checks.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
