Details
-
Bug
-
Resolution: Fixed
-
P1: Critical
-
6.2, 6.5, 6.7, 6.8.0 FF
-
None
-
3
-
cb3faeba3 (dev), f53074c74 (6.8), a56aba7d1 (6.7), 0a4b037b9 (tqtc/lts-6.5), 6baf85f92 (tqtc/lts-6.2)
-
Foundation Sprint 113
Description
FP types are partially ordered, so comparison of containers that store NaN values should take it into consideration.
However, in practice we see that comparison of two QLists holding NaN values provides different results than simply comparing two NaN values:
QList<float> l1{std::numeric_limits<float>::quiet_NaN()}; QList<float> l2{std::numeric_limits<float>::quiet_NaN()}; qDebug() << (l1 == l2); // true qDebug() << (l1.front() == l2.front()); // false
The reason for that is most probably qtbase/db89349bdba2fcc03b2f7e2d23f549a9ec5dc0e3 (https://codereview.qt-project.org/c/qt/qtbase/+/282602) which added an optimization that uses memcmp() for arithmetic types.
Attachments
For Gerrit Dashboard: QTBUG-127473 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
578358,2 | Test op==() for sequence containers with FP NaN values | dev | qt/qtbase | Status: ABANDONED | -1 | 0 |
578359,6 | QArrayDataOps: fix FP equality comparison | dev | qt/qtbase | Status: MERGED | +2 | +1 |
579053,2 | QArrayDataOps: fix FP equality comparison | 6.8 | qt/qtbase | Status: MERGED | +2 | 0 |
579174,2 | QArrayDataOps: fix FP equality comparison | 6.7 | qt/qtbase | Status: MERGED | +2 | 0 |
579184,2 | QArrayDataOps: fix FP equality comparison | tqtc/lts-6.5 | qt/tqtc-qtbase | Status: MERGED | +2 | 0 |
579327,5 | QArrayDataOps: fix FP equality comparison | tqtc/lts-6.2 | qt/tqtc-qtbase | Status: MERGED | +2 | 0 |