Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-99615

Most QMutableEventPoint usage depends on Undefined Behaviour



    • 8
    • 6852c20502 (qt/qtbase/dev) 6852c20502 (qt/tqtc-qtbase/dev)
    • Team Two Foundation Sprint 49


      There are two uses of QMutableEventPoint:

      • copying a QEventPoint's properties and allowing manipulation. In this case, the object is an actual QMutableEventPoint, and it's use is ok, albeit made complicated by missing conversions from and to QEventPoint.
      • casting a QEventPoint to QMutableEventPoint in order to manipulate properties that QEventPoint doesn't provide getters for. This usage depends on UB (invalid casts and invalid member calls d/t object type mismatch), and we must get rid of it.

      My current thinking is that it's ok to have a QMutableEventPoint, as a private subclass of QEventPoint, with explicit conversions from and to QEventPoint, so as to not require casting. At the same time, like mentioned in QTBUG-99563 for QMutable*Event, we could have static setter methods that can act directly on QEventPoints.

      I have a working prototype that implements the above two ideas, but the main issue here is the unclear sharing behaviour: most setters neither detach() nor check for d == nullptr, with the exception of setTimestamp() and updateFrom(), which conditionally and unconditionally detach, respectively. This could be handled by only allowing move conversion from/to QEventPoint, which is probably the way to go for the first iteration.


        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              mmutz Marc Mutz
              mmutz Marc Mutz
              Vladimir Minenko Vladimir Minenko
              Alex Blasche Alex Blasche
              0 Vote for this issue
              3 Start watching this issue



                Gerrit Reviews

                  There are no open Gerrit changes