AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Document a peculiarity that might plausibly confuse readers

Browse Source 
It at first sight seems perverse to null-check a variable we've
repeatedly dereferenced before, without visibly setting it since;
however, its address was stored where an event handler could get at
it, to clear it if deleting the object it points to. The check against
null really is needed, but the reason is non-obvious; so document the
reason and save the next developers to come this way some confusion.

In the process, relocate a related comment that belonged one line
earlier.

Change-Id: Id67b86edc5a9a76a827d66b5c0abcd017d98a2bb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This commit is contained in:
Edward Welbourne 2021-03-22 11:19:53 +01:00
parent 27ebeeb50e
commit 1bdc74ad7b
1 changed files with 5 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/corelib/kernel/qtimerinfo_unix.cpp
View File

@ -1,6 +1,6 @@
/****************************************************************************
**
** Copyright (C) 2016 The Qt Company Ltd.
** Copyright (C) 2021 The Qt Company Ltd.
** Copyright (C) 2016 Intel Corporation.
** Contact: https://www.qt.io/licensing/
**
@ -631,13 +631,16 @@ int QTimerInfoList::activateTimers()
if (currentTimerInfo->interval > 0)
n_act++;
// Send event, but don't allow it to recurse:
if (!currentTimerInfo->activateRef) {
// send event, but don't allow it to recurse
currentTimerInfo->activateRef = &currentTimerInfo;
QTimerEvent e(currentTimerInfo->id);
QCoreApplication::sendEvent(currentTimerInfo->obj, &e);
// Storing currentTimerInfo's address in its activateRef allows the
// handling of that event to clear this local variable on deletion
// of the object it points to - if it didn't, clear activateRef:
if (currentTimerInfo)
currentTimerInfo->activateRef = nullptr;
}