Document a peculiarity that might plausibly confuse readers

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>

1 files changed, 5 insertions, 2 deletions

diff --git a/src/corelib/kernel/qtimerinfo_unix.cpp b/src/corelib/kernel/qtimerinfo_unix.cpp
index bcaaf7af05..db4d4b1188 100644
--- a/src/corelib/kernel/qtimerinfo_unix.cpp
+++ b/src/corelib/kernel/qtimerinfo_unix.cpp
@@ -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;
         }