395d23fbb3
It's very annoying to try and debug why the values are different when QCOMPARE(_xx) says they are the same: FAIL! : tst_QCborStreamReader::floatingPoint(QByteArray:2.^64-epsilon) The computed value is expected to be equal to the baseline, but is not Computed (reader.toDouble()): 1.84467440737e+19 Baseline (expectedValue) : 1.84467440737e+19 Now: Computed (reader.toDouble()): 1.844674407370955e+19 (0x1.fffffffffffffp+63) Baseline (expectedValue) : 1.844674407370952e+19 (0x1.ffffffffffffp+63) %a formatting is required by C11, which is required for C++17, which we require. I've modified tst_selftests to normalize the representation of floating point numbers on-the-fly, so we don't have to deal with differences in how the different libc print floating point values[1]. This allows us to remove qtestcase.cpp's massageExponent() function, if we want to in the future. I've chosen to use std::regex instead of QRegularExpression so we don't break tst_selftests in case we break QRE or our PCRE dependency. I've also moved the floating point comparison that was in tst_cmptest to tst_float, where all other floating point were. Ideally we'd also print the NaN payload when not zeroes, but that's a job for another day. [ChangeLog][QtTest] QtTest now prints floating point values in hexadecimal notation and has increased the precision for the decimal format, so different values can be observed in the output when QCOMPARE or QCOMPARE_xx fail. [1] For example, whether 1 is 0x1p+0 or 0x8p-3. For me, the 0x1 prefix is objectively more useful because the part after the dot matches the mantissa bits in the variable and the exponent matches the stored exponent (minus the bias). Task-number: QTBUG-85779 Task-number: QTBUG-127280 Change-Id: Idc6cb070c750d2acbd26fffdc8defad7d7ae8733 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>