29bc12777c
It missed some occurrences of 0 when only looking into uninstantiated template code, as Clang doesn't model them with an ImplicitCastExpr, even if the target is known to be a (dependent) pointer type. Looking into all template instantiations of course carries the risk that a given use of 0 is meant to be interpreted as a pointer in some and as an integer in other instantiations. But the only case where that happened in the current code base is RegistryValueList::getElement (include/registry/registry.hxx), where {} is arguably a better choice anyway. (And which would presumably also hold for any future such cases.) Change-Id: I708bcfc8bedc0a49c9282d7814eb325afa29905c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128462 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> |
||
---|---|---|
.. | ||
access_control.hxx | ||
basemutex.hxx | ||
bootstrap.hxx | ||
compbase.hxx | ||
compbase1.hxx | ||
compbase2.hxx | ||
compbase3.hxx | ||
compbase4.hxx | ||
compbase5.hxx | ||
compbase6.hxx | ||
compbase7.hxx | ||
compbase8.hxx | ||
compbase9.hxx | ||
compbase10.hxx | ||
compbase11.hxx | ||
compbase12.hxx | ||
compbase_ex.hxx | ||
component.hxx | ||
component_context.hxx | ||
cppuhelperdllapi.h | ||
exc_hlp.hxx | ||
factory.hxx | ||
findsofficepath.h | ||
implbase.hxx | ||
implbase1.hxx | ||
implbase2.hxx | ||
implbase3.hxx | ||
implbase4.hxx | ||
implbase5.hxx | ||
implbase6.hxx | ||
implbase7.hxx | ||
implbase8.hxx | ||
implbase9.hxx | ||
implbase10.hxx | ||
implbase11.hxx | ||
implbase12.hxx | ||
implbase13.hxx | ||
implbase_ex.hxx | ||
implbase_ex_post.hxx | ||
implbase_ex_pre.hxx | ||
implementationentry.hxx | ||
interfacecontainer.h | ||
interfacecontainer.hxx | ||
propertysetmixin.hxx | ||
propshlp.hxx | ||
proptypehlp.h | ||
proptypehlp.hxx | ||
queryinterface.hxx | ||
shlib.hxx | ||
supportsservice.hxx | ||
TODO | ||
typeprovider.hxx | ||
unourl.hxx | ||
weak.hxx | ||
weakagg.hxx | ||
weakref.hxx |