Details
-
Bug
-
Resolution: Fixed
-
P1: Critical
-
6.0, 6.5.0 RC
-
None
-
f5c55da04 (dev), 6b41e4198 (6.5), 44a471d34 (tqtc/lts-6.2)
Description
6589f2ed0cf7 (Shawn Rutledge 2019-05-31 08:38:16 +0200) #ifndef QT_NO_DEBUG_STREAM 6589f2ed0cf7 (Shawn Rutledge 2019-05-31 08:38:16 +0200) QDebug operator<<(QDebug debug, const QInputDevice *device) 6589f2ed0cf7 (Shawn Rutledge 2019-05-31 08:38:16 +0200) { 836c0b5a24f5 (Shawn Rutledge 2020-06-30 12:06:37 +0200) const QInputDevicePrivate *d = QInputDevicePrivate::get(device); 836c0b5a24f5 (Shawn Rutledge 2020-06-30 12:06:37 +0200) if (d->pointingDeviceType) 836c0b5a24f5 (Shawn Rutledge 2020-06-30 12:06:37 +0200) return operator<<(debug, static_cast<const QPointingDevice *>(device)); 6589f2ed0cf7 (Shawn Rutledge 2019-05-31 08:38:16 +0200) QDebugStateSaver saver(debug); 6589f2ed0cf7 (Shawn Rutledge 2019-05-31 08:38:16 +0200) debug.nospace(); 6589f2ed0cf7 (Shawn Rutledge 2019-05-31 08:38:16 +0200) debug.noquote();
Since https://codereview.qt-project.org/c/qt/qtbase/+/306260
QInputDevicePrivate::get() calls
static const QObjectPrivate *get(const QObject *o) { return o->d_func(); }
so we should check for null before we call that.
It's just surprising that I didn't notice for this long. Of course events should have non-null devices... but this came up in the context of writing a QAIM subclass to visualize the device hierarchy, in which the QModelIndex::internalPointer might be null, or the parent might be null if it's a master device.