[Development] Are we free of code that checks this isn't null?

Marc Mutz marc.mutz at kdab.com
Fri Mar 4 09:58:53 CET 2016

On Friday 04 March 2016 07:52:15 Thiago Macieira wrote:
> Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html):
> > Value range propagation now assumes that the this pointer of C++ member
> > functions is non-null. This eliminates common null pointer checks but
> > also breaks some non-conforming code-bases (such as Qt-5, Chromium,
> > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks
> > can be used. Wrong code can be identified by using -fsanitize=undefined.
> Are we free of such mistakes? Or do we need to enable -fno-delete-null-
> pointer-checks?

This comes to mind;

  QPointer<QObject> that = this;
  // ...
  if (!that) return;

Not sure it's affected, though.

Don't know off-handedly anything else that where this == nullptr would be 
valid. Only way to find out is to enable -fno-delete-null-pointer-checks except 
for -developer-build and trying to fix the ubsan issues.

We should eventually put a ubsan build into the CI, we're not /that/ far away 
from building cleanly. It's some time since I last checked, but I can't 
remember any 3rd-party libs triggering in a ubsan Qt builds.

/me upgrades to GCC 6.


Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts

More information about the Development mailing list