[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.
Thanks,
Marc
--
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