It's a Qt 3 compatibility vehicle, and as such inherits the now-alien
property to distinguish empty and null strings. Particularly worrisome
is the following asymmetry:
QString("") == QString::null // false
QString("") == QString(QString::null) // true
Instead of fixing this behavior, recognize that people might use it as
a weird way to call isNull(), albeit one that once was idiomatic, and
simply deprecate everything that deals with QString::null.
[ChangeLog][QtCore][QString] QString::null is now deprecated. When
used to construct a QString, use QString() instead. When used to
compare to a QString, replace with QString::isNull().
Change-Id: I9f7e84a92522c75666da15f49324c500ae93af42
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
For the windows file system engine, we add an extra macro to use
library loading if configured to do so, but avoid it on WinRT, as
none of the symbols would be found.
We also QT_REQUIRE_CONFIG(library) in the library headers and
exclude the sources from the build if library loading is disabled.
This, in turn, makes it necessary to clean up some header inclusions.
Change-Id: I2b152cb5b47a2658996b6f4702b038536a5704ec
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Parameters passed by value, like local function variables, are subject
to NRVO/return-by-move already, so adding std::move, even disguised as
qMove(), makes Clang warn about a pessimizing move.
Change-Id: I7d59bfee4cf7ecddee0874ee489367044c702643
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
QLocale::matchingLocales() simply created each locale using the basic
data, without (unless the matching conditions stipulated Language C)
applying number-options hacks that it applies everywhere else, when
creating the C locale. Thus the C locale in its returned list (if it
wasn't the only entry) ended up with the default number options,
without omiting separators in numbers. Thus QLocale::c() didn't
actually appear as an entry in the list. Discovered while
investigating QTBUG-58947.
Added a dumb autotest that checks various ways of getting the C locale
do actually give us equal locale objects. Fixed matchingLocales() to
apply the same hack as is used elsewhere for the C locale.
Change-Id: I263f31da623052b63171f5b5a83c65802383df21
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace all QT_NO_PROCESS with QT_CONFIG(process), define it in
qconfig-bootstrapped.h, add QT_REQUIRE_CONFIG(process) to the qprocess
headers, exclude the sources from compilation when switched off, guard
header inclusions in places where compilation without QProcess seems
supported, drop some unused includes, and fix some tests that were
apparently designed to work with QT_NO_PROCESS but failed to.
Change-Id: Ieceea2504dea6fdf43b81c7c6b65c547b01b9714
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Unlike setTimeSpec, this forgot to clear the bit when detaching. So it's
possible that some further use of the flags could incorrectly conclude
that the data was short and then proceed to corrupt the pointer.
The example from QTBUG-59061 caused this because toUTC() -> toTimeSpec()
calls setMSecsSinceEpoch which left the bit set; then addDays() calls
setDateTime(), which calls checkValidDateTime() and that corrupted the
pointer. This problem was more visible on 32-bit systems because no
QDateTime was short (except for default constructed ones), but it
can happen on 64-bit with sufficiently large dates.
Task-number: QTBUG-59061
Change-Id: Ibc5c715fda334a75bd2efffd14a562a375a4e69b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's only used in the autotests, and it private API, so
downgrade from Q_CORE_EXPORT to Q_AUTOTEST_EXPORT.
Fix a use of QTimeZonePrivate functions unprotected by
QT_BUILD_INTERNAL in tst_qtimezone.cpp.
Change-Id: I70eaea06f8fcf2983aeafb6894c3a5d2a4b272a7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some format and parse tests for time and date-time depended on locale
but had test data for the C locale (so fail if the test-environment
has, e.g., LANG=de_DE@utf8). So impose the C locale (until Qt 6).
The date-time test did *some* attempts at fixing for locale, but
failed to handle am/pm; and we do have "### Qt 6" comments in
Q(Date|Time)+::fromString indicating that we intend to switch these
methods to use the C locale by default (which shall fix this once and
for all). So rip out the incomplete localization now and test we work
properly at least when the locale used *is* C. Add a comment to the
matching QDate test to rip out its (presently adequate) matching code
once we do get to Qt 6 and make fromString() use the C locale.
QDateTimeParser uses systemLocale(), which is initialized the first
time it gets accessed; so we need to frob the locale *early*; doing so
in the test-class constructor is about as early as we conveniently
can; and seems to work (while doing it in individual tests does not).
(There is no point rolling back at the end; the QSystemLocale global
has been set up by then, so the roll-back would merely leave the
global out of sync with setlocale() and the environment.)
Task-number: QTBUG-58728
Change-Id: Ifa6778a80276050a099387a6dab15a1096be7561
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Like the lvalue QVector::append() overload, when we reallocate,
we need to take a copy of the function's argument because the
reference will get stale upon reallocation.
Add a test.
[ChangeLog][QtCore][QVarLengthArray] Fixed a bug involving
appending an item already in the container to the container
again.
Change-Id: I06eeed6cb383dd5924e47a302bb3d1666d04c8e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Systematic testing in tst_QStringApiSymmetry revealed a bug in
QStringRef::toLatin1(): a null input did not result in a null output,
but an empty one. This is fixed, for consistency with
QString::toLatin1(), and QString(Ref)::toUtf8(), which behaved
correctly already.
The same bug was found in QString(Ref)::toLocal8Bit(), which is
particularly hideous, as it's documented to fall back to toLatin1(),
which preserves null inputs. Fixed, too.
[ChangeLog][QtCore][QString] toLocal8Bit() now preserves nullness of
the input QString (outputs null QByteArray).
[ChangeLog][QtCore][QStringRef] toLocal8Bit() and toLatin1() now
preserve nullness of the input QStringRef (output null QByteArrays).
Change-Id: I7026211922c287e03d07e89edbad2987aa646e51
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
tst_QDateTime::operator_insert_extract() was setting the time-zone and
taking care to restore it at the end of the test; however, if the test
were to fail, the restore would be skipped. Package the zone-setting
and restore in a class instance, so that premature return can't bypass
the restore.
Change-Id: I3df63260da17e481ef4d0d107d9f0fdea3e147e7
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
currencySymbol == "$" does not mean negative currency values will be formatted
as "($value)". With all locales I have on my mac machines (10.11/10.12) the
result is different from what this test expects. Also, the results are very
different for different locales. Apparently, we never saw this problem before
since in our CI "macs" we never have US Dollar/en_US selected in System Preferences.
Task-number: QTBUG-58784
Change-Id: Ic2c3a3172bf1e715e99092ddee8f461b216d995a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This reverts commit b0c1e07d64.
The unit tests it introduced trigger errors with the macOS and
Win32 implementations, which means the there's something seriously
wrong with either the API, our implementation or the tests.
Revert for now until this gets fixed. Blacklisting was also the
wrong tool to use. The tests should have used QEXPECT_FAIL.
Change-Id: Ida20c6bbe0c019835a22464535029585e8e1e367
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There weren't any, at all.
Testing on the CI showed that the implementation is broken on
macOS, and, to a lesser extent, on Windows, so blacklist the
failing tests until the implementation can be fixed. No need
to hold back testing the other implementations.
Task-number: QTBUG-58737
Change-Id: I9ae16ab778dbe2e95a6ca5e0bae00df4bad65cb2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When a non-QString-backed mode (via the (QChar*, int) ctor) was added
for Qt 4.5, the author forgot to adjust the setCaseSensitivity()
function. It still uses q_pattern instead of (p.uc, p.len) as the
pattern for which to create the skip-table. Since there is no
setPattern() overload for this mode, the correctness of the matcher is
not harmed by this, but its performance degrades to that of a linear
scan: the skip-table, being filled from an empty pattern, will be
all-zeros, sending bm_find() into the 'possible match' case at every
character.
Since matching is still correct, but slow, it's not possible to write
a test for this. I did, however, leave my attempts in the auto-test,
for when we add QStringView overloads of setPattern() which will then
be able to expose the bug.
Change-Id: I7b803e8624b0352a0a974900affbbfc0c260d93b
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The first one was already suppressed for GCC, so also do that for clang:
/Users/erik/dev/qt5-dev/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp:1076:16: warning: format string is not a string literal (potentially insecure)
[-Wformat-security]
a.sprintf( zero );
^~~~
/Users/erik/dev/qt5-dev/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp:1076:16: note: treat the string as an argument to avoid this
a.sprintf( zero );
^
"%s",
The second one could also occur with other compilers, so fix it in a
generic way.
/Users/erik/dev/qt5-dev/qtbase/tests/auto/corelib/tools/qstring/tst_qstring.cpp:6382:5: warning: ignoring return value of function declared with
warn_unused_result attribute [-Wunused-result]
string.repeated(3);
^~~~~~~~~~~~~~~ ~
2 warnings generated.
Change-Id: Id999179e795580a37b5be673ee54d6fa1a006dd7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There was an off-by-one error in the while loop for aarch64: we start
counting at 0 for the first position, so the last valid input position
is "a+7", not 8.
This wasn't covered by the tests, nor was the SSE2 version, so now there
are also tests for both versions.
Change-Id: I7eb8c5708e6179f45ea56885b0e66e1a37969c1d
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Do not wait up to the timeout ms after already having waited several
times. At the same time upgrade to using the QDeadlineTimer which
is designed for this purpose.
Change-Id: Iaf5e4f4655605d5143ce91040c6eb6706752e504
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is a version of QByteArrayMatcher that calculates the
Boyer-Moore skip table at compile-time instead of at run-time,
making this class more generally applicable than QByteArray-
Matcher itself, at least for statically-known strings.
The compile-time part requires C++14 constexpr support, but
the class should compile and work even in C++98 mode, just
with runtime initialization of the skip-table.
While touching tst_qbytearraymatcher, clean up the static
global QByteArrayMatchers there and add tests with needles
longer than 255 characters for QByteArrayMatcher, too.
[ChangeLog][QtCore] Added QStaticByteArrayMatcher.
Change-Id: I0662f262ab19b79ae4096f3ab384d5b3ada72347
Reviewed-by: David Faure <david.faure@kdab.com>
... along with the two matching unused methods of QDateTime's test.
Change-Id: Id11a4b1b0132587f0df451d49c0043e9425d87ad
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For language "Traditional Chinese" on iOS with region "US",
the logic was formerly to attempt a match on country/language/script (fail),
followed by country/language (which would result in script defaulting to
"Simplified"). Now, the logic is to try language/script first if script is
specified. Failing that, language/country will be attempted.
Task-number: QTBUG-39639
Change-Id: I75a774b1e66686e95167ff221458a97a7ea2660d
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jason Erb <jason.erb@sparist.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This new function does the same as newRow(), except that it has a less confusing
name (in line with _add_Column()), and accepts printf-style arguments to avoid
the need to newRow(qPrintable(QString::asprintf())), a common pattern in client
code. It uses qvsnprintf() under the hoods, avoiding the need for the QString
const char* round-trip.
Port all in-tree users of newRow(qPrintable(QString::asnprintf())) to the new
function.
Change-Id: Icd5de9b7ea4f6759d98080ec30f5aecadb8bec39
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
An overflow-check needed the datum for the "min" test to be minus the
datum for the "max" test; so explicitly make the former use -max()
instead of synthesising it as min()+1. This simplifies the
explanation of why that's needed, too. Clarify the overflow-check's
comment at the same time.
Change-Id: I41f56764fdf5e8c749bfae7a685e5fb77d37b3a8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ISO 14443-3 is for nfc communication and uses 2 different checksums.
The existing one is from ISO 3309 and the other one is from ITU-V.41.
Both are needed to implement an own transport layer defined in ISO
14443-4 to allow nfc commands with a length above 250 byte independent
from the smartphone.
This change will avoid code duplication in QNearFieldTarget.
The private function qNfcChecksum is a copy of qChecksum.
Change-Id: I790ffec8e2ea46f88b2db6f48b64fdcb140e7b70
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The separator character is inserted in the resulting array
after every byte and is useful for MAC address output like
01:23:45🆎cd:ef, Hash fingerprints, or low level data
debug output.
[ChangeLog][QtCore][QByteArray] Added toHex() overload to
insert a separator character between the hex bytes.
Change-Id: Ibe436094badc02f3ade7751aa8b5d690599941d4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously, a zone-based time would claim to be GMT, rather than
identifying its zone properly. Sadly, testing this reveals that
proprietary operating systems don't handle abbreviations ideally.
Task-number: QTBUG-57320
Task-number: QTBUG-57298
Change-Id: I8d8b7fffdbf65ac6178a65f5fc2df4d25afb1a14
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the time is specified relative to a zone, the ISO date produced
lacked its offset suffix; all zones were treated as if they were local
time. Handle zone as for an offset from UTC and ensure we do set the
date-time objects's offset from UTC when it's zone-based.
Change-Id: I7c9896bb8ec0a9d89df14a6e94b005174ab9e943
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's a const parameter, so no sense copying it.
Change-Id: I4a673a6a60af9bfe7cb61ce28de2aa295fa1d069
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make it const, initialize it instead of assigning, consolidate testing
of it round some #if-ery.
Change-Id: I2efbf58292a0edd2ceb3da8d3cc16246e84a3bac
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Such mappings are ill-defined in the presence of daylight-savings time
(DST); at its transitions, you need information about whether DST is
active or not to determine the correct UTC value. Existing code did
not have a way to be told that hint, so could not be correct.
Fixing this required changing the (thankfully private) APIs by which
QDateTime accessed QTimeZone's information stipulated by zone time.
In QDateTime, this required propagating the needed hint, when DST
status was known.
QAndroidTimeZonePrivate overloaded QTimeZonePrivate::dataForLocalTime
with an implementation that works whenever !hasTransitions(); the base
implementation handled this case lamely, so I've moved the Android
implementation there, to have only one place for both re-writes.
Amended tst_QDateTime's expected failures; passing a date and time to
the constructor *is* ambiguous when the moment indicated is in a
transition. I have changed which way we resolve that ambiguity.
Added round-trip test of QDateTime's fromMSecs/toMSecs (but as a
QTimeZone test, since that's what's actually getting tested), based on
a test-case from Marko Kangas. Initially failed for various zones,
each at one hour-offset; and, on some platforms, for some zones, at
all offsets. These last revealed that a platform may claim to have
zone information yet, for some zones, lack it (or have very incomplete
information). In each case, despite this, the platform does give
offsetFromUtc(). (The test also found another pre-existing bug on
Linux; fixed in an earlier commit.)
To accommodate these gaps in transition data, the transition-based
code now falls back to the offsetFromUtc()-based code (used when there
are no transitions) if it can't find a previous transition (which, in
any case, it needs to do its job).
Task-number: QTBUG-56460
Task-number: QTBUG-56397
Task-number: QTBUG-52284
Change-Id: I2f7422a9e9d3767940b1901d887c6a2c1f36ac9f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
tst_qtcpsocket.cpp:606:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
tst_qtcpsocket.cpp:670:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
tst_qfile.cpp(2661): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
tst_qarraydata.cpp(760): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
main.cpp:40:33: warning: ignoring return value of 'char* fgets(char*, int, FILE*)', declared with attribute warn_unused_result [-Wunused-result]
Change-Id: I80ccef29b71af6a2c3d45a79aedaeb37f49bba72
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
Compare to QLatin1String and use reinterpret_cast to fix MSVC warning:
tst_qstring.cpp(1271): warning C4312: 'type cast': conversion from 'unsigned int' to 'void *' of greater size
Change-Id: I4f26d72f0fad59e09636fe609a2772309a688e5c
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Remove most type traits from qtypetraits.h, but keep the custom
implementation of is_signed/is_unsigned. This gets rid of
BSD-3 licensed code from Google in a public header (hugh!).
The custom implementations for is_signed/is_unsigned are kept
because the implementations in gcc's standard headers do not
work as we expect for enums - both is_signed and is_unsigned
always returns false there - see also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027
[ChangeLog][QtCore][General] Qt now relies on type traits from
the C++ standard library.
Change-Id: I3f2188b46949f04ca4482a6ac9afd3482103f0e1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Consistent with other Unix platforms, and internally consistent between tests,
as a lot of tests were already applying CONFIG -= app_bundle manually.
Change-Id: Icd2b7e1c08015b26137af60ff82fddbc753f0ff4
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The Qt::ISODate format strips milliseconds, so a new format is introduced
that keeps the milliseconds. A new format was chosen over fixing the
existing format due to the behavioral change of suddenly having ms
as part of Qt::ISODate.
Change-Id: If8b852daed068cce8eee9b61a7cd4576bc763443
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
CFAbsoluteTime is measured in seconds, represented by a double,
so when converting milliseconds to CFAbsoluteTime we may get a
slight error due to missing precision in double to represent
the milliseconds exactly. By rounding to the closest millisecond
when converting back, we avoid truncating and being one ms off.
Change-Id: If1e99f97b000fb8cb893ddfc5d7ba81096c0ea88
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Liang Qi
Marc Mutz
Ulf Hermann
Edward Welbourne
Thiago Macieira
Timur Pocheptsov
Erik Verbruggen
Allan Sandfeld Jensen
Jake Petroules
Jason Erb
Lars Schmertmann
Andre Hartmann
Friedemann Kleint
Kai Koehne
Tor Arne Vestbø