QRect::center() should be defined for any
QRect(x1,y1,x2,x2), INT_MIN <= x1, x2, y1, y2 <= INT_MAX
because the average of two signed integers is always
representable as a signed integer.
But not when it's calculated as (x1+x2)/2, since that
expression overflows when x1 > INT_MAX - x2.
Instead of playing games with Hacker's Delight-style
expressions, or use Google's patented algorithm, which
requires two divisions, take advantage of the fact that
int is not intmax_t and perform the calculation in the
qint64 domain. The cast back to int is always well-
defined since, as mentioned, the result is always
representable in an int.
Fix a test-case that expected a nonsensical result due
to overflow.
[ChangeLog][QtCore][QRect] Fixed integer overflow in
center(). This fixes the result for some corner-cases
like a 1x1 rectangle at (INT_MIN, INT_MIN), for which
the previous implementation could return anything
(due to invoking undefined behavior), but commonly
returned (0, 0).
Change-Id: I1a885ca6dff770327dd31655c3eb473fcfeb8878
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
The compiler can statically check that this is undefined
behavior:
tst_qrect.cpp:3173:52: warning: integer overflow in expression [-Woverflow]
<< QRect(QPoint(0,0), QPoint(INT_MAX+(0-INT_MIN),INT_MAX+(0-INT_MIN)));
~^~
tst_qrect.cpp:3173:72: warning: integer overflow in expression [-Woverflow]
<< QRect(QPoint(0,0), QPoint(INT_MAX+(0-INT_MIN),INT_MAX+(0-INT_MIN)));
~^~
Fix by skipping the test (like most of the others are
in the block).
Change-Id: I359a5e16db6c660c9f11d7dd8fbb40730bd63887
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
It made us skip the rest of the test, not just the small set of
sub-tests that were conditioned by the if () in whose else it sat.
Change-Id: I5e914e0aeb9d5ba44b21966d071aaccbc590365d
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Setting conflicts to isSet & DaySection cleared it if we hadn't seen
the day stipulated, even if there had been a conflict (e.g. over year)
before we hit the day-of-week that didn't match the (unset, so
defaulting to) 1st of the month. Explicitly test for conflict and
only set conflicts (to true) if there is a conflict. Added regression
test.
Change-Id: I7363eb66a8bb808d341738d14969039834f50db8
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Uses a time derived via .toUTC() to ensure the .toLocalTime() comes
out at the time we expect.
Task-number: QTBUG-49008
Change-Id: I2005127929c7eab1b7a3cbaba8d21df8c9585d17
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDateTime::toString for Qt::TextDate unconditionally uses the system
locale (because QDate::shortDayName and QDate::shortMonthName do).
Setting the default QLocale has no effect. If you ask me, those two
QDate methods are buggy, but they are documented that way.
Change-Id: I408dcb81ba654c929f25ffff1427366b04da5a43
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The important one is EET, for the benefit of our CI system; but other
European zones and the USA's coastal zones likely have enough hackers
in them to make this worth checking.
Change-Id: Idcc703bce29808e1a0a6279680cc8d3cbed38dac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Time zones change on the whim of politicians. Consequently, we can
seem to be in CET/CEST or on UTC (because we tested sample dates when
our zone coincided) when we aren't (i.e. we're in a materially
different zone at the time probed by some particular test). Make the
initialization of the globals that test this more robust against
governmental meddling and document the unfixable problem with Algeria:
a DST transition *on the epoch*.
Change-Id: I17c5c81d339b80af12f4ffab367e28052dd6c2fa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are several European time zones; the only one relevant to the
tests here is CET. They won't work with WET, GMT or EET. So name
them and related variables for CET, not for Europe.
CET's summer-time isn't called CST; and the (existing) spring forward
test works only in CET/CEST, not elsewhere in Europe.
Change-Id: I55c7544bf792de7495700b749b935ec534831d8b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are three deprecated language codes that Java still uses for the
locale so we need to account for these inside QLocale by mapping them to
the right language.
Task-number: QTBUG-49632
Change-Id: Ib66b3f2763e085f7384228f2490b048bb56be259
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
When QDateTime::addDate() and friends sanitize their end-state, they
were using the DST status of their start-state (if known) to control
it. This lead to misguided results and, in particular, inconsistent
results given that a raw-constructed QDateTime comes into being
ignorant of its DST, while a .toLocalTime() one knows its DST.
Furthermore, the code to do this was triplicated, tricky and poorly
explained. So pull it out into a local static function and explain
what it's doing, and why, more clearly and only once.
Task-number: QTBUG-49008
Change-Id: Ia4bb3c5e9267fff8bb963ea705267998218ed623
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
This partially reverts commit e486d69133.
It broke too many users, even though all of them deserved to be broken.
The new functionality will be provided by differently-named functions,
where possible (problem: equality operators).
I did not revert the fix for the off-by-one error in
tst_qtextdocumentfragment.cpp.
I also didn't revert the change in the inequality relational operators,
since for all strings s1, s2 and s2' where s2' is s2 truncated at the
first NUL, s1 < s2 ⟺ s1 < s2' (since NUL < c for any c != 0), and,
trivially, for ≤, >, ≥, too. This does not hold for = and ≠, of course,
since "foo\0bar" ≠ "foo".
[ChangeLog][Important Behavior Changes][EDITORIAL] Reverted: All
conversions from QByteArray to QString now preserve embedded NULs...
Change-Id: If4b47048b39ae5be6ed08e6d91809626a67ea7f5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Widen its interval (to work in more TZs) and test spring as well as
autumn. Anywhere that does have a DST transition probably has it
between August and December; and there's no benefit to using a narrow
window.
There's also no sense skipping the test if we don't know there's a DST
transition: the test should still work, it just won't be testing
anything (about DST transitions).
Combine date and time checks into date-time checks, so that, when one
of them fails, QCOMPARE lets us know how the other changed, too.
Task-number: QTBUG-49008
Change-Id: I145b939ffef0dd0b54fd0e3cdf72a159c57ec00b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Off-by-one error: we should have calculated whether the current year is
leap, not the next year. This affected any 53-week leap years.
Task-number: QTBUG-50273
Change-Id: I134ce5db2f82468585ffffff14264cb9f12998fd
Reviewed-by: Martin Klapetek <mklapetek@kde.org>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Binding a reference to the nullptr is undefined
behavior.
Just skip that particular test when 'ptr' is null.
Found by UBSan:
tests/auto/corelib/tools/qsharedpointer/tst_qsharedpointer.cpp:258:32: runtime error: reference binding to null pointer of type 'struct Data'
Change-Id: I125588b9d269a6f76716d660d03142f409513885
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Probably correct.
The question is just why this code has survived for so many years.
Change-Id: Iaf01850476f9b066243abebb9ee6c5928d7ada19
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
The test was improved by:
- Use QCOMPARE instead of QVERIFY
- Use QTRY_ macro instead arbitrary qWait
- Use longer time line
The test executes faster and it should be less vulnerable to
an unreliable timer.
Change-Id: I92675015a6251b47eaf20b0fc916f3a36b52d783
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
The test run faster and it less vulnerable to an inaccurate time.
Change-Id: I19475095395dcf1e6d47fdbba5eeffabab1fc7b9
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Now the test is less fragile to time and it executes 4s faster
Change-Id: Id3eb8ed2c03317e7d2f2c3cd17f889a8d8e7e5b4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
The test still can fail because 1s is quite a short time.
Change-Id: I6f42c182f2932d5a053f6a69667210529c9a7697
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
TEST_HELPER_INSTALLS cannot be used on platforms with no
QProcess support.
Change-Id: I2a6a283d94ca4487fc628449c53fc37140dd291d
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
If the LHS is detached and has existing capacity that is large
enough to hold the RHS, re-use the memory instead of allocating
a new buffer and throwing away the old.
Change-Id: I53d42825da92c264c7301e8e771cba9fb35c321b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It should compile, since the std::shared_ptr does.
[ChangeLog][QtCore][QSharedPointer] Fixed a problem that would cause a
compilation error when constructing a QSharedPointer of a const type
when the type derives from QEnableSharedFromThis.
Task-number: QTBUG-49748
Change-Id: I8de47ed6c7be4847b99bffff141c84f5e0b6bea8
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Only add C++14 to the project configuration when C++14 support is
available on the platform. Adding it because the platform supports
C++11 doesn't work when the platform _only_ supports C++11 (e.g.,
QNX 6.6.0).
Task-number: QTBUG-49491
Change-Id: I15de38bb06d912a314b9dd18c80b513cc06a855e
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When that happens, we need to detach (in-place conversion won't work),
so we recurse back into the same function, but the template version that
does detaching.
Task-number: QTBUG-49181
Change-Id: Idba8c29717f34c70a58fffff1412fea3acc95f98
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Test that stepping into the missing hour lands us somewhere sane.
Check that raw instance and product of .toLocalTime() agree.
Task-number: QTBUG-49008
Change-Id: I430382ae223bcb43b151d2d6054ecbdd7edc8a47
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
warning: 'typemsg1' may be used uninitialized in this function [-Wmaybe-uninitialized]
Change-Id: Ie68d279eccb003a2ca5a0116eea336cbc8776660
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
* Georgian lari currency symbol
* A large collection of CJK unified ideographs
* Emoji symbols and symbol modifiers
* Letters to support the Ik language in Uganda, Kulango in
the Côte d’Ivoire, and other languages of Africa
* A set of lowercase Cherokee syllables, forming case pairs
with the existing Cherokee characters
* The Ahom script for support of the Tai Ahom language in India
* Arabic letters to support Arwi—the Tamil language written in the Arabic script
For more details, see http://www.unicode.org/versions/Unicode8.0.0/
[ChangeLog][QtCore] Unicode data updated to v.8.0
Change-Id: If255f95c9c45655b721369a116299da3cabbba0a
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
QLatin1String wasn't really tested except as a drive-by.
Unearthed a discrepancy with docs. Fixed the docs.
Change-Id: I1246bb33888132edbc4e22da792a480a156357bf
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Numbers formatted in the C locale should not use group
separators by default.
[ChangeLog][QtCore][QLocale] The C locale does not use group separators
when formatting numbers any more.
Task-number: QTBUG-4044
Task-number: QTBUG-3068
Change-Id: Ia647a72efc11fecd66d22f9253562b1d4ef58168
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Now all Qt sequential containers consistently provide reverse iterators.
The associative ones, by way of not returning std::pair from op*, can't
just use std::reverse_iterator. They would miss .key() and .value() methods.
So that has to wait for 5.7.
The reverse versions of the new key_iterators can also just use
std::reverse_iterator, but I'm afraid that after bikeshedding over
keyRBegin() vs. rKeyBegin() vs. reverseKeyBegin() vs. rkbegin()
vs. krbegin() (<-- of course, what else?), it would anyway be too
late for 5.6, so defer, too.
[ChangeLog][QtCore][QLinkedList/QSet] Added rbegin(), crbegin(), rend(), crend(),
and reverse_iterator and const_reverse_iterator typedefs.
Task-number: QTBUG-25919
Change-Id: I58316fffade469e9a42c61d7aa1455ae3443fd94
Reviewed-by: Sérgio Martins <sergio.martins@kdab.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
QVersionNumber is now public API.
Change-Id: I5b21b6ce5f1651158b6f29bc6f06e5d4e133bed8
Reviewed-by: Keith Gardner <kreios4004@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Source files should not be executable.
Change-Id: If9b9eaa6c8c7348ca6f48fa9253f3540e95aca37
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
QByteArray::operator< and friends had their logic reversed.
Task-number: QTBUG-48350
Change-Id: I625209cc922b47e78dfb8de9fe100411f285a628
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The timeZone() function used to assert when called on such an object
(or, for a release build, return an invalid time zone).
Change-Id: I6ae8316b2ad76f1f868e2498f7ce8aa3fcabf4a6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In some cases it's not possible to use QT_HASH_SEED, specially when
we need to set the environment variable from inside the application,
as dynamically loaded libraries or plugins may create static QHash
instances. That would set qt_qhash_seed to a value different from
-1 and skip the env var value.
For those cases, and when we still want to set qt_qhash_seed, we
provide a way to enforce its value.
Auto-tests accessing qt_qhash_seed directly have been updated
accordingly. Usage in qdoc, uic and rcc has been left as is
for the time being.
Change-Id: I3b35b4fa0223c83b1348a6508641905a2a63266f
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
