... avoiding one more memory allocation, and giving us access to
QCryptographicHashPrivate::result, for use in subsequent commits.
The only real adjustment to users of QMACPrivate::messageHash is that
instead of
messageHash.result();
they now need to use
messageHash.finalizeUnchecked();
messageHash.resultView() // .toByteArray()
I.e. explicitly finalize.
Pick-to: 6.5
Change-Id: I80b1158b062554bbf8afa7241674a892de27f204
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To be reused in QMessageAuthenticationCode.
Pick-to: 6.5
Change-Id: Ie4f003ad38ce9072cf6ee52ef2d7a63438e4d7ae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With the OpenSSL3 code allocating state on the heap instead of in
QCH::Private's inline union, reset() should be faster than even a
static hash() call. Even in the non-OpenSSL3 case, using less
QCH::Private objects to do the same thing means we increase effective
data cache size.
Pick-to: 6.5
Change-Id: I0b1347864081169a24c5d349702931afdab6c5bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This just complicates the code, for the small benefit of avoiding a
messageHash seeding from an empty key that then has to be reset.
This lazy initialization is in the way of using QCH's SmallByteArray
for the key, which this author thinks is the more important
optimization, because it will allow passing keys by QByteArrayView,
removing the impedance mismatch between QMAC and QCH.
Since the QMAC API doesn't distinguish between the absence of a key,
and the presence of a null (ie. empty) key, we can't not call
initMessageHash() when the key is empty, so we should suggest to pass
the actual key to the constructor as often as possible, and use
setKey() only to change the key afterwards.
[ChangeLog][QtCore][QMessageAuthenticationCode] No longer delays
processing of the key to the first setData() or result() call. While
passing a default-constructed key to the constructor and then calling
setKey() continues to work, for optimal performance, we suggest to
pass the actual key as a constructor argument and call setKey() only
to change the key.
Pick-to: 6.5
Change-Id: If0a078f37a16f8306f77d2b2bd5dacf23ce5c3e2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Like in QCryptographicHash, it's never re-set, so, like there, make it immutable.
Pick-to: 6.5
Change-Id: I88f3dc15febffa8950256aedc5e8d1385fc86ddd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
... basically inlining static QCH::hash(), which, however, accepts
only one piece of data, while we have two.
Avoids the memory allocation of the QCH d-pointer. The toByteArray()
is now the only memory allocation left in finalizeUnchecked(), and
will be removed in a subsequent commit.
Pick-to: 6.5
Change-Id: I7549d6e1c116a4cdc29dac74b867dfa6647022a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rename it to QSmallByteArray, and make the maximum size a template
argument. Initialize m_size to 0, to avoid a partially-formed
default-constructed objects (default-constructed containers should
always be in the empty state).
As a drive-by, fix placement of some {'s.
Don't move it into a header of its own, yet, as it lacks a lot of
features expected of a generally-reusable class. Maybe one day.
This is in preparation of re-using the class to hold the key in
QMessageAuthenticationCode.
Pick-to: 6.5
Change-Id: Iee77e03e50afdf2ebc5889feeead344bef8ab3e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... from the end().
It was lonely down there, and prone to be overlooked when performing
early returns in the #ifdef'ery above, as witnessed by the early
returns in the OpenSSL3 code.
Amends 1fe74c3bd3, itself amending
633c136596.
Pick-to: 6.5
Change-Id: I8c941ecb5c4755d8823b2161544cf6f7fe75a239
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It was confusing entry capacity with the bucket capacity. The value
maxNumBuckets() returned was the maximum number of entries. This issue
was harmless: we would just fail to cap the maximum to an allocatable
size. But the array new[] in the Data constructors would have capped the
maximum anyway (by way of throwing std::bad_alloc).
So instead of trying to calculate what the maximum bucket count is so we
can cap at that, simplify the calculation of the next power of 2 while
preventing it from overflowing in our calculations. We continue to rely
on new[] throwing when we return count that is larger than the maximum
allocatable.
This commit changes the load factor for QHashes containing exactly a
number of elements that is exactly a power of two. Previously, it would
be loaded at 50%, now it's at 25%. For this reason, tst_QSet::squeeze
needed to be fixed to depend less on the implementation details.
Pick-to: 6.5
Change-Id: I9671dee8ceb64aa9b9cafffd17415f3856c358a0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Saw this on my FreeBSD VM. The backtrace() function thought the nearest
symbol to something was "_ZTSNSt3__110__function6__baseIFbPvS2_EEE",
which decoded to
typeinfo name for std::__1::__function::__base<bool (void*, void*)>
The function pointer type inside parameter threw the decoder for a loop
and caused it to crash with the failed assertion in qbytearray.h:
inline char QByteArray::at(qsizetype i) const
{ Q_ASSERT(size_t(i) < size_t(size())); return d.data()[i]; }
I noticed this
- because tst_qtimer hung
- because qFormatLogMessage deadlocked acquiring QMessagePattern::mutex
- because the logging recursed
- because qCleanupFuncinfo failed an assertion while formatting the
backtrace (my QT_MESSAGE_PATTERN has %{backtrace})
- because QTimer::~QTimer -> QObject::killTimer printed a warning
- because tst_QTimer::moveToThread produces warnings
Pick-to: 5.15 6.2 6.4 6.5
Change-Id: Ieec322d73c1e40ad95c8fffd17464f86e9725991
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
They share so many things, and QMAC is lacking so many of the changes
QCH has received over the last few months, that it seems QMAC is
better off being implemented in the QCH TU.
Among other things, this will allow QMAC to use QCHPrivate for its
implementation, drastically reducing the number of memory allocations
required to perform HMAC operations.
Pick-to: 6.5
Change-Id: I3c81a52e3a9ad57c14c91c16bc347f215fd407ba
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This brings the code in line with the sibling code in
QMessageAuthenticationCode, which now has a simiar split between
finalize() and finalizeUnchecked().
Pick-to: 6.5
Change-Id: I10701d59d56617ab32fae0df47371f0464e9cc77
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QIODevice::read(ptr, n) returns qint64, not int. The returned values
are, however, confined to the interval [-1,1024], so no harm
done. Make the narrowing explicit, though.
Pick-to: 6.5
Change-Id: I5f95292ca6e05f0f402e7258e590593eff361255
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... of creating a Private instead of the public class on the stack.
This avoids its memory-allocation, as well as the overhead of the mutex
in finalize().
Task-number: QTBUG-111347
Pick-to: 6.5
Change-Id: I4d144fcfadc0b8c9ba78d395ff7279b2d5d7b050
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
While QMessageAuthenticationCode is not copyable, result() is
nevertheless const, so a user could prepare a
QMessageAuthenticationCode object with setKey() and addData(), pass it
by const reference to two threads, which each just call result() on
it. This should be safe, but because result() performed lazy
evaluation without being internally synchronized, this would cause
data races.
Fix in the same was as b904de43a5 did
for QCryptographicHash. See there for a detailed discussion of the
solution.
Fixes: QTBUG-111347
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I1feb380973c480ad6268349a0a46ac471b9ca0f7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
<bit> exists in C++20 and is properly both constexpr and optimized. But
in C++17 mode, we don't have constexpr bitops and instead elect to have
performance at runtime instead. But somewhere along the line, either
when they were added, when C++20 <bit> support was, or in any of the
bugfixes for other compilers, the nesting of #ifdef got messed up and we
declared that we had constexpr builtins for MSVC in C++17 too.
The macro QT_HAS_CONSTEXPR_BUILTINS isn't supposed to be used by anyone
else... but we ended up not being able to use it ourselves either. So
I'm renaming it to a more precise label.
Pick-to: 6.5
Change-Id: I9671dee8ceb64aa9b9cafffd1741b9b4060c9753
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This brings the code in line with its sibling code in
QCryptographicHash and prepares for a static hash() optimization and
the fixing of the result() re-entrancy issue (QTBUG-111347).
Task-number: QTBUG-111347
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I3d0c0cd2a37c2bbeb60974307ff138e26b82bf69
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The goal of this function is to ensure that dst is _always_
NUL-terminated. The only exception is if there's no space to write
even one NUL byte, of course, but not when src is nullptr but dst
would have space.
Update the docs to the new behavior and make them more precise.
Fix a test that assumed qstrncpy() would not write to dst for
(dst, nullptr, 10).
[ChangeLog][QtCore][qstrncpy()] Now NUL-terminates the target
buffer even when the source pointer is nullptr, provided the
target buffer has space for at least one byte.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I7806d8c71e260f8f02b79af7b6ce94f23599dd69
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When Qt is configured to return nullptr from isNull() QStrings
(QT5_NULL_STRINGS != 1), then we'd be feeding a nullptr src into
strncpy(), which is UB. I couldn't rule the case of a null QString
lexeme out with local reasoning, seeing as the code is in the else
branch of an if (lexeme.startsWith(~~~) && lexeme.endsWith(~~~)), so
it might be null.
Instead of porting to qstrncpy(), which can deal with a nullptr src
(albeit up to recently, badly), note that the strncpy + the char[]
allocation is a qstrdup(), so use that instead. This also does away
with the queasiness of taking the size() of a UTF-16 string to limit
strncpy() for the L1-recoded version (which, in this instance is safe,
as toLatin1().constData() is NUL-terminated, but in some other
instances was not).
As a drive-by, make sure we don't leak the strdup()'ed string if the
emplace_back() fails.
Amends be98fa32c7.
Qt 5 is not affected, as constData() never returns nullptr there.
Pick-to: 6.5 6.4 6.2
Change-Id: I178d356e560d2749cd6ce0b9364c710a2d117304
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The only user of the function, QCollatorPrivate::init(), passes
QLocalePrivate::bcp47Name().constData(). bcp47Name() may return a
default-constructed QByteArray (e.g. for QLocale::AnyLanguage), so
constData() may be nullptr (QT5_NULL_STRINGS != 1). Passing nullptr to
strncmp() or strncpy() is UB, though.
Instead of using the nullptr-hardened q... versions of these
functions, check name for nullptr once, at the top of the function,
and avoid all the lookup code that follows and is known to fail
(because windows_to_iso_list does not contain empty entries).
This way, we take advantage of the std functions' UB for performance
reasons (fewer repeated nullptr checks), instead of being taken
advantage of.
Qt 5 is not affected, as constData() never returns nullptr there.
Pick-to: 6.5 6.4 6.2
Change-Id: I980dace2bca1e983ac526e89fadeb92239ab5f11
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test documented behavior and serv as a baseline for future changes.
Change-Id: I36a914694d5244c89f28f3e403e11d65492a5eef
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This completes the triad uint/ulong/qulonglong, ensuring that one of
them will be size_t and one of them will be uintptr_t (size_t and
uintptr_t don't have to be the same type). The signeds ensure one of
them will be ptrdiff_t too.
Pick-to: 6.5
Change-Id: I9671dee8ceb64aa9b9cafffd17415a0bfcbd68b7
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
This reverts commit 81ce878f55.
Reason for revert: The native type is DOMRect, and in Qt, converters
to/from native types stick to the native capitalisation (e.g. fromCGRect
or fromNSString).
Change-Id: Ic44ec79849fc6accdce1153471dd1ad9117e57ce
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The class claims to be thread safe, however, when e.g.
one thread is calling setMaxThreadCount() and the second
is calling maxThreadCount() at the same time for the same thread pool
instance, the latter may receive rubbish data.
Protect all public setters/getters with a mutex.
Pick-to: 6.5 6.4
Change-Id: Ief29d017d4f80443fa1ae06f6b20872f07588768
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We want to be able to use those from qtdeclarative. Clearly, they are
intended to be inline.
Task-number: QTBUG-108789
Change-Id: I3560e9b58213c4f41dbf6553021f3d6187960e8b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Don't return duplicate path entries from calling
QStandardPaths::standardLocations() and as a pass by no empty entries
either.
Pick-to: 6.5
Task-number: QTBUG-104892
Change-Id: If05b20d2c07d75428cb572d9549a39cf21bdef99
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Found in API review: from/toUintArray() is too generic a name, make
sure its name gives enough context.
Pick-to: 6.5
Change-Id: Ie10ff06ae11a5e168c4c91b60a9698a41d0429fc
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Because it's QDomNode, not QDOMNode, either (abbreviations aren't
supposed to be all-caps in Qt).
Found in API review.
Pick-to: 6.5
Change-Id: I37bcd8c38d396709d11c4eab035cdfd2145eb245
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In the same vein as e24df8bc72 for
emplace(it, v) and insert(it, rv), this patch addresses the identical
issues in insert(it, n, v). The solution is unsurprisingly the same:
q_rotate() after a resize(size() + n, v).
The 6.2- code will need to look different, because resize(n, v) didn't
exist there.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I1ce91969abc20f2a1e5d05a8545b009a2e0994f6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It seems like we'll need this in lots of other places, too.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I767495c2eb02a2fc85b6f835ad9003fa89315c7f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The deprecated implementation of QSharedMemory and QSystemSemaphore
are not correctly guarded by the deprecation macros, and thus it's
causing compilation errors when we disable deprecated code.
As a drive-by, change the deprecate version from 6.9 to 6.10
as requested.
Change-Id: Icfed181c27248b9e1381101a64523419097dd1da
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Removed `_DEFAULT_SOURCE` as it was not consistent, and possible didn't
work in the first place, and was masked by the exclusion of
`io/qfilesystemengine_unix.cpp`.
Amends fc3a9ee601.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I8036e66d29d5ec88608d284436b4e8719144f06d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's documented to return -1 when the file doesn't exist, so we gain
nothing by saying a file we ourselves must have created doesn't exist.
Change-Id: I12a088d1ae424825abd3fffd171dfa1de6705787
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This collides with a similarly name struct/object in qmutex.cpp.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I29404f092db523e21f310b4e5b3cd8cc35170e4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
And on 64-bit platforms, use a 64-bit integer, which removes a
subtraction from the matching code.
The loop in bytearrayToLongLong() looks like, on x86-64:
movabsq $4294983168, %rsi
.L1217:
movzbl (%rdx), %ecx
cmpl $64, %ecx
ja .L1216
btq %rcx, %rsi
jnc .L1216
incq %rdx
cmpq %rbx, %rdx
jne .L1217
Change-Id: I3d74c753055744deb8acfffd1723d8b51e151432
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Replace qlocaltime.cpp's qt_tzname() with qTzName() in
qtenvironmentvariables{_p.h,.cpp} so as to put the access to the
standard library global under the control of the same lock as controls
all Qt's calls to tzset() and functions that behave as if they called
it. This avoids UB on access to the global during a call to any of
these functions. Take care to use the lock only for the shortest time
needed.
This simplifies both callers and lets a QDTParser method escape to
qdatetimeparser.cpp to become a simple local static function instead
of a class method defined in a separate compilation unit.
Change-Id: I5ddee5641f2ed7b5676ece10375a1d5232eb7f22
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We so far refetched the first observer after evaluating bindings, as
binding evaluating might change the list of observers.
However, that approach did not take into account that the 'this' pointer
might no longer be valid after binding evaluation: In case of a
QObjectBindableProperty (or a QObjectCompatProperty), binding evaluation
might cause a reallocation of the binding storage, and consequently the
invalidation of the QPropertyBindingData.
Fix this by refetching the QPropertyBindingData from the storage (if a
storage has been provided, which is always the case for the affected
classes).
Fixes: QTBUG-111268
Pick-to: 6.5 6.4 6.2
Change-Id: Ie7e143a0bbb18f1c3f88a81dd9b31e6af463584f
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If the application executable was built against a pre-macOS 11 SDK, macOS
will report its version as 10.16 on every OS from macOS 11 and up, for
compatibility reasons.
From Qt 6.2 and up, we require at least Xcode 12 with the macOS 11 SDK
to build Qt applications, so normally this should not be an issue, but
in the case where the Qt 'app' is a plugin library hosted by a third
party host application, the host application determines the behavior,
and we might end up in the compatibility situation after all.
However, since the Qt app was built against at least the macOS 11 SDK,
we know that it can/should handle the new version number scheme, and
we can resolve the real version number for QOperatingSystemVersion.
We do that by launching the sysctl binary with the SYSTEM_VERSION_COMPAT
environment variable set to 0, which is the supported way of disabling
the compatibility mode.
Now that we have the real version number we can use that for the
deployment target check via qt_apple_check_os_version(), but we
still need to account for possible failures in reading the plist
file.
We can also simplify the QOperatingSystemVersion::MacOSBigSur
definition, now that we always know the app the should be able
to handle major versions above 10.
Pick-to: 6.5 6.4 6.2
Task-number: QTBUG-111114
Change-Id: I2a2756381c31b195f7b8800c5008a87b37114080
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The [first, first+n) and [out, out+n) ranges cannot possibly overlap, as
by definition the former contains live objects while the latter points
into uninitialized storage. So we can use memcpy here, and not memmove.
Change-Id: I4a1b39f73ffa67915c5252938554f45f4444293e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Document the potential issue caused by using QT_ANDROID_EXTRA_LIBS from
the project build tree.
Inspired by QTBUG-111173.
Pick-to: 6.5
Change-Id: I39fcda6e19b15eb13a390978230944dad41ec8d1
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Application delivered via the macOS or iOS App Store might have their
libraries encrypted, in which case we can not read any of the sections
of the binary until it has been dlopened.
This was causing issues for our plugin loading code, which assumed we
could read the .qtmetadata section of a yet to be loaded plugin to
determine its suitability, before loading it.
We now detect whether a library is encrypted during the Mach-O parsing,
and propagate this back to QLibraryPrivate::updatePluginState(),
which can handle the case by explicitly loading the library before
continuing with metadata validation. We still ensure that the library
has a .qtmetadata section, so that we don't need to dlopen any random
library in our path.
This does mean that we will potentially load more plugins than we
need, and since the Qt version validation happens as part of meta
data validation, we might dlopen() incompatible plugins, but it's
expected that in an App Store deployment scenario you control both
the versioning and set of shipped plugins, so this should not be
an issue in practice.
As encrypted libraries are only produced for apps that are fully
published to the App Store, and then deployed via MDM, VPP, or
Apple Configurator 2, we don't have an easy way to test this,
but the existing code paths should be unaffected, and hopefully
this patch improves the situation for the encrypted library case.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: Iff733505f7067ce5571854ea978bc95e8376e347
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
After commit b5a54d488c, we now use QCollator and so no toLower()
when caching the filename, we can re-use it from the cache after
sorting.
Change-Id: I8602a11c6f68cfe61db3ec6330596066cd257dab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's possible for time_t to overflow and time() to thus fail, so check
against that. We don't need to think about the last second of 1969 for
this, as that won't be the current time for anyone running this code.
Change-Id: I14f34d5d3e2ab9713593fcd06d6771e1d7f357ee
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Marc Mutz
Thiago Macieira
Ahmad Samir
Volker Hilsheimer
Jarek Kobus
Ulf Hermann
Assam Boudjelthia
Amir Masoud Abdol
Antti Määttä
Yuhang Zhao
Friedemann Kleint
Tim Blechmann
Edward Welbourne
Fabian Kosmale
Tor Arne Vestbø
Giuseppe D'Angelo
Alexey Edelev