When QXcbConnection::xi2SetupDevices() reacts to a device hierarchy
event and re-discovers an already-known slave device, it doesn't call
xi2SetupSlavePointerDevice() again. I.e. it won't attempt to add it to
m_touchDevices or m_tabletData because it was already known. So it
should not clear m_touchDevices or m_tabletData either, but only remove
the touch devices that are known to have disappeared. Tablet styli
normally come and go from proximity, so it's ok to avoid deleting the
corresponding device data.
Also fix some other failure cases after testing hotplugging more with
tests/manual/inputdevices: there should be no crashes, no duplicated
devices after plugging (although the QAIM might have a bug that makes
it look that way), no leftover instances after unplugging.
Amends 2a9d93efc6
Pick-to: 6.6 6.5 6.5.2
Fixes: QTBUG-114334
Change-Id: I30f5e532f7dd3a465d56ecdd34d893cbadbf0453
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Right-clicking in a QKeySequenceEdit opens the usual context menu for a
line edit, which generates a focusOut event. QKeySequenceEdit finishes
the recording when it loses focus, which includes deselecting the text.
We should not finish or deselect if the focusOut event has focusReason
FocusReasonPopup, as otherwise users cannot copy the text (keyboard
shortcuts don't work for that, obviously).
Pick-to: 6.6
Task-number: QTBUG-114624
Change-Id: I0b3c535c189151daa29cf17640493f3353e6394b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Like commit 91f6460aff which added support
for Windows, this commit does the same for our final major OS.
The Darwin kernel exposes a set of __ulock_{wait,wait2,wake} APIs [1],
but these APIs are marked as private, so we cannot rely on them being
stable, nor we can use these APIs in builds of Qt intended for
the Apple App Store. By wholesale disabling the use of the APIs
in App Store compliant builds, and runtime checking availability
of the APIs when we do build them in, we should be safe, unless
the semantics of the APIs change in ways we haven't accounted for,
but that's a risk we're willing to take.
Note that libc++ uses these private APIs to implement P1135R5
(the C++20 synchronization library) [2], but that use is under
a "special permission" from the Darwin team, and meant only for
use in the Apple vendored version of libc++ shipped with their
operating systems, where they control both the kernel and the
standard library.
[1] https://github.com/apple-oss-distributions/xnu/blob/xnu-8792.81.2/bsd/sys/ulock.h
[2] https://reviews.llvm.org/D68480.
Change-Id: Ib709fc1585f647a98d54fffd16663b4965458404
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Warning C4275 non dll-interface class 'QJsonValueConstRef' used as base for dll-interface class 'QJsonValueRef' UniRemoteAdapter C:\qt\Qt6.5.1\6.5.1\msvc2019_64\include\QtCore\qjsonvalue.h 219
Pick-to: 6.5 6.6
Fixes: QTBUG-114629
Change-Id: I443cf0c8a76243eead33fffd176930f96c43eb47
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Fixes an issue with generated code where the name of an enclosing
namespace is identical to an enum class type, when Q_ENUM_NS is used.
Consider:
namespace a {
Q_NAMESPACE
namespace b {
enum class b { Key, Key2 };
Q_ENUM_NS(b);
}
}
moc generated code such as:
Q_CONSTINIT const QMetaObject a:🅱️:staticMetaObject = { {
...
qt_incomplete_metaTypeArray<qt_meta_stringdata_CLASSaSCOPEbENDCLASS_t,
// enum 'TestEnum'
QtPrivate::TypeAndForceComplete<b::b, std::true_type>,
// Q_OBJECT / Q_GADGET
QtPrivate::TypeAndForceComplete<void, std::true_type>
>,
nullptr
} };
which confused the compiler:
error: ‘b’ is not a member of ‘a:🅱️:b
83 | QtPrivate::TypeAndForceComplete<b::b, std::true_type>,
Fixes: QTBUG-112996
Pick-to: 6.6
Change-Id: I37aee83c32efe96cc9d6c2bd0bdb9ba80bb7b8a7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The Freedesktop Icon Theme Specification [1] describes that,
if a theme does not specify anything for its 'Inherits' key,
"implementations are required to add the 'hicolor' theme to
the inheritance tree. An implementation may optionally add
other default themes in between the last specified theme and
the hicolor theme."
And later, when describing the lookup algorithm, that "The
lookup is done first in the current theme, and then recursively
in each of the current theme's parents, and finally in the
default theme called 'hicolor' (implementations may add more
default themes before 'hicolor', but 'hicolor' must be last)".
But it doesn't explicitly describe the behavior when a theme
does specify a list of inherited themes via the 'Inherits' key,
and this list explicitly includes 'hicolor'.
In that case, our custom fallback theme, which we inject after
the theme's explicit parents, will be prioritized after 'hicolor'.
As it's likely that the theme author added 'hicolor' to their
parent list to ensure that 'hicolor' is at some point consulted,
but didn't intent it to be priorized, and that the spec puts focus
on 'hicolor' being last, it seems reasonable that we can move the
'hicolor' theme to the end of the fallback list, and as a result
always prioritize fallbackThemeName() over 'hicolor'.
[ChangeLog][QtGui][QIcon] The 'hicolor' theme will now always be
prioritized last when looking up fallback themes, even if
explicitly declared as a theme parent in a theme.
[1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html
Pick-to: 6.6
Change-Id: I76538e4e7e9e395f9e5a38e704c60fb6b9688885
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
We still need to consult fallbackThemeName() when computing the
parent list for an individual theme, as the Freedesktop Theme Icon
spec mandates that the "hicolor" theme comes last, but we no longer
need to do explicit fallback to fallbackThemeName() if a theme is
not found.
Pick-to: 6.5 6.6
Change-Id: I6c0b5a45d8258c5b6eaa761402944a735b1606ba
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The use of fallback icons should not depend on a theme being set.
[ChangeLog][QtGui][QIcon] QIcon::fallbackSearchPaths() will now be consulted
for fallback icons even if the current theme name is empty.
Pick-to: 6.5 6.6
Change-Id: Ia8d14062de7c53601fd9dac30f87a9e672aa2207
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
My fault, I had added that bit of the docs a while ago.
Pick-to: 6.6
Change-Id: I1fa2c10b0f7263e12b5b2a4d18f362c702f9d831
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We would previously only use the fallback theme for themes that did
not exist, or for themes that did not declare any parent theme.
We now unconditionally use the fallback theme, even for themes that
declare their own parent themes, so that a QIcon::fromTheme("foo")
that doesn't exist in the current theme, nor any of its parents,
nor in "hicolor", will still be looked up in the fallback theme.
The reason this seemed to work in the existing tests was because
our test themes inherit system themes such as crystalsvg and gnome,
and we didn't provide a hicolor theme. Any of these themes missing
would lead us into the code path where we use the fallback theme
for a missing theme, masking that fact that we had not added the
fallback theme to the list of fallbacks for the theme that had
explicit parents declared.
The logic has been moved out of the theme parsing and into an
accessor in QIconTheme, so that we're not caching the fallback
theme lookup.
[ChangeLog][QtGui][QIcon] QIcon::fallbackThemeName() will now be
used as fallback even for themes that declare a parent theme.
Pick-to: 6.5 6.6
Change-Id: Ib0ce1dfe97030f23893460ed624073a719a3ebd1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Setting a fallback theme will affect the lookup strategy, so we need
to invalidate earlier lookups.
Pick-to: 6.5 6.6
Change-Id: I962245ddb3a20b7798d5ce831ed8a369b0ab76b4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QThemeIconEngine takes care of creating a new icon engine when
the icon theme key changes, so we don't need to invalidate the
entire QIcon cache.
Pick-to: 6.6
Change-Id: Ie3bca00a9146d1f429b2a6f8ab0b39e15834d158
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The logic for invalidating a theme QIcon when the platform theme
changed, or when the user set an explicit icon theme, was tied
to QIconLoaderEngine, so any platform theme implementing
QPlatformTheme::createIconEngine() with a custom icon engine
would not take part in this cache invalidation.
As we want users of QIcon::fromTheme to be agnostic to where the
icon is actually coming from, and have a consistent behavior for
the various QIcon APIs for setting explicit themes, the logic
for invalidating the themed icon has now been moved up one
layer, to a new QThemeIconEngine, that is responsible for
lazily creating the actual engine based on the name. The
engine proxies the actual icon loading through to the
real engine via a new QProxyIconEngine helper class.
Pick-to: 6.6
Change-Id: I474589981f751d7467e3073533cba542182f2d36
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This is not needed, as main loop just works with awaited calls
thanks to JS suspender objects with JSPI enabled.
Fixes: QTBUG-114651
Change-Id: I94e187953ac8cec5c999f1b02508efecc19641f6
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The platform theme's icon loading logic may still have changed, even
if the theme name has not, so we still need to invalidate the theme
cache.
Pick-to: 6.5 6.6
Change-Id: Id3635c235fadb007df86d93ce3beb5622d26b8bf
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The fallback logic in QIconLoader::updateSystemTheme() has been
updated to match QIconLoader::ensureInitialized(), by using the
systemFallbackThemeName() directly, rather than the possibly
user set QIconLoader::fallbackThemeName().
Pick-to: 6.5 6.6
Change-Id: Ib5aab62bbfb22683d3bddf87c4e798eca4a5af62
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We cache the system theme name in QIconLoader, so when a theme change
comes in we need to update the system icon theme name regardless of
whether a user theme has been set.
The updated system theme name will not be reflected through the
QiconLoader::themeNamed() unless the user theme is cleared/unset.
Pick-to: 6.6 6.5
Change-Id: Id949e55e2fa12e40818ba54cf2a10ce48fe10815
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Adding the "assets:" prefix to BaseName leads to wrong names returned by
QFileInfo{"assets:/path/to/file"}.fileName().
Instead to return "file" it returns "assets:/file" which is not the
expected result.
Fixes: QTBUG-114576
Fixes: QTBUG-114219
Fixes: QTBUG-112261
Pick-to: 6.6 6.5 6.5.2
Change-Id: I574bf325300c0aedef68b1b183fa837144ad63c6
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Assorted code was iterating from tranCache().cbegin() to
tranCache().cend(), and getting away with it because CoW means
tranCache()'s two distinct returns were referencing the same pimpl,
but let's make tranCache() return a const ref so that these calls are
all accessing the same object (and we get complaints if we do anything
non-const with it via this method).
Axivion-Id: qt_qtbase_dev_linux:SV1685
Pick-to: 5.15 6.2 6.5 6.6
Change-Id: If43ccf37c2b27837e5462cb4a0eeb07f0045cbfe
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Move the implementation qRequireVersion() to prevent having
to include qdebug.h which pulls in many other headers.
Amends b5d874e36f.
Fix missing include introduced by
3a553507a1.
Pick-to: 6.6
Task-number: QTBUG-114214
Task-number: QTBUG-97601
Change-Id: Iba68ffca95061666d9458ffa5700d07c7669da5b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reworked the code to list supported ciphers for Schannel
backend to provide the proper cipher names and cipher
properties.
Note: restricting the used ciphers for a TLS connection
is only supported for TLS 1.2 yet!
[ChangeLog][QtNetwork][QSslConfiguration] Add support for
listing supported ciphers with Schannel backend.
Change-Id: Idfc17335ec489315387a3e84b7a76a263be22378
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Currently items can get stuck in a hovered state when all fingers are
lifted from a touchscreen. This is because we don't react to the
WM_POINTERLEAVE event from Windows. With this patch we translate a
WM_POINTERLEAVE event to a LeaveEvent to remove the hover state from
QtQuick items.
Fixes: QTBUG-62912
Pick-to: 6.5 6.6
Change-Id: I8a6fb6b7ec77457854a75e20277565d1eb89bab6
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The signal can deviate from QWidget::isVisible().
This patch clarifies the signal's documentation.
Since its name suggests that it is in sync with QWidget::isVisible(),
A TODO comment is added to consider deprication in Qt7.
It appears to be more reliable to listen to hide/show events.
Pick-to: 6.6 6.5
Fixes: QTBUG-48161
Change-Id: I43aa16c2ecb4877abd8effb7da8e07576438d6d2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This was used as a work-around for Q5MutexLocker's UB downcasting
QBasicMutex to QMutex, and for some unspecified performance
improvements.
Now that Q6MutexLocker is a template, the two are almost
token-by-token identical, so we can remove this work-around and use
QMutexLocker directly.
Partially reverts aea500d5d7.
Pick-to: 6.6 6.5 6.2
Change-Id: I57ef5c53999869aa3454fbbaad884c1d18591b2a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
On FreeBSD, the environ variable doesn't come from libc, but is instead
inserted during linking. See ccf74b5928
(5.6) for more information.
But instead of allowing undefined symbols in QtCore, let's use a weakref
to environ so this one symbol is allowed to be undefined. It won't be,
but the linker doesn't know.
FreeBSD appears to be the only BSD to require this. We used to apply the
same linker option to OpenBSD in Qt 5, but neither the OpenBSD or nor
the NetBSD ports trees[1][2] carry a patch for this, so I don't think
it's necessary.
[1] https://github.com/openbsd/ports/tree/master/x11/qt6/qtbase/patches
[2] https://github.com/NetBSD/pkgsrc/tree/trunk/x11/qt6-qtbase/patches
Pick-to: 6.6
Change-Id: I63b988479db546dabffcfffd17661c839014771a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We so far only handled them if they came at the very start of the method
declaration.
This patch ensures that we also handle them after the meta-method tag
(but before the actual type).
Unifying parseFunction and parseMaybeFunction to avoid the need to
munally keep them in sync is left for another day.
Fixes: QTBUG-111330
Pick-to: 6.6 6.5 6.5.2 6.2
Change-Id: Ic94edb69f04b9150aea2c8e6d004a8b9e5cf12ec
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The GTK platform theme (and possibly others) emit theme change
when the named icon theme changes, but that was not propagated
to QIconLoader.
We now call QIconLoader::updateSystemTheme(), but note that
if a user theme has been set we ignore the system theme update
and will end up with a stale value, even if the user theme is
later cleared. This will be fixed in a follow up commit.
Pick-to: 6.6 6.5
Change-Id: I40b537f3618f44d396db0c7ca67e515dfcdfba44
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The qstdweb::bindForever function will be introduced soon for binding
callbacks with forever lifetime. For now, since submodules have to be
adapted first, introduce a stub function to port qtmultimedia which
uses Promise::make - it will have its interface changed with
relation to bindForever.
Task-number: QTBUG-112296
Change-Id: I578e1633574e11877a8f5ec14d0f00dfd7c766bf
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
QFontEngine tries to generate glyphs for ASCII control characters. Those
characters have no glyphs and should therefore not be generated.
Task-number: QTBUG-113848
Change-Id: Ib15a50c642d8bc92bc007ab5522aebc5a7b2993d
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Some of our tools don't have the `-h`, or `-v` flag, or it could be
that the `-v` flag also prints the entire `--help` as well, e.g.,
`androiddeployqt`. When running in Jenkins, this may lead to a message
box being shown and consequently stopping the build. By customizing the
flag per tool, and limiting the TRY_RUN to tools that support `-v` or
`--version`, we can avoid this.
Also removed TRY_RUN from `macdeployqt` which doesn't need it anyway.
Amend 41b32cd2c4
Pick-to: 6.5.2 6.5 6.6
Fixes: QTBUG-114530
Change-Id: I78e3344d2553c0050c285ae86f2310bd373c6c57
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The method is more than a plain getter, so keep it with the other
logic of the class.
Pick-to: 6.5 6.6
Change-Id: I34aa185a51f04e3db3c1918f9723e53f33e5e9e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The example was moved to qtnetwork but its documentation
still referred to old paths under /examples/corelib.
Add documentation dependency to qtwidgets as RSS listing
example's docs link to a number of widget classes.
Pick-to: 6.6 6.5
Change-Id: Ief1c9dc2ca38ba3da1fe3039500292147ec4cc7d
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
If the style changes while a popup is open (or about to close),
the popup will change style as well before it's hidden. And
this can result in the popup window briefly ending up smaller
than what it needs to be, in order to fit all the menu items.
In that case, it will show 'up' and 'down' widgets in the
menu that auto scrolls it when hovered. And all this can
happen for a split second while the menu is about to close
(as a result of the user clicking on a menu item).
A bug happens because of this if you click on the last menu
item in the list, and this causes the style to change. In
that case, the 'down' widget will end up directly underneath
the mouse for a split second, which will trigger an auto-scroll
timer to start. This timer will trigger a bit later, after
the popup has been hidden, and scroll the list view a bit down.
The result is that the next time you open the popup, it ends up
at the wrong place on the screen in a failed attempt to center
the current index on top of the combobox.
This patch will make sure that we always scroll the list view
to the top before we start calculating where the popup should
be placed on the screen. Otherwise the geometry ends up wrong
since the popup will anyway be resized (if possible) to fit
all the menu items before it's shown and should therefore not
take scrolling into account.
Pick-to: 6.6 6.5
Fixes: QTBUG-113765
Change-Id: I61b5b832904de471c2303fc67325feec322b1449
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Like commit 91f6460aff which added support
for Windows. This API is documented and has apparently been present in
FreeBSD for a long while.
The DragonflyBSD API is very similar, but I don't have one to confirm
that I've coded correctly. OpenBSD and NetBSD may have similar APIs, but
I haven't even researched them. We're open to contributions, though.
Change-Id: I63b988479db546dabffcfffd1766bc431fed614b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This allows us to use absolute times on Linux (today) and FreeBSD
(soon), plus simplifies both QMutex and QSemaphore.
Change-Id: I63b988479db546dabffcfffd17675a182aa528fa
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Makes it cleaner when I add more OSes.
Change-Id: I63b988479db546dabffcfffd1766bee2e6370b94
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Setting parents for WASM platform windows is now supported. This means
that windows now reside in a hierarchical window tree, with the screen
and individual windows being nodes (QWasmWindowTreeNode), each
maintaining their own child window stack.
The divs backing windows are properly reparented in response to Qt
window parent changes, so that the html structure reflects what is
happening in Qt.
Change-Id: I55c91d90caf58714342dcd747043967ebfdf96bb
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
QHeaderView::mouseMoveEvent started autoscroll without propagating the
event's mouse position to QAbstractItemViewPrivate::draggedPosition.
This data member always containing QPoint() has lead to right drags not
causing an autoscroll at all. Left drags with a scroll offset just
kept scrolling until the offset was 0.
The missing propagation has been added.
As a drive by, dead code has been removed and the local variable pos
has been constified.
Fixes: QTBUG-113573
Pick-to: 6.6 6.5
Change-Id: I7b194dfc71abea6f2bbaaae18270c80eb15afb4d
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Most of the QWS (Qt Windowing System) classes from
the Qt 4 times are cleaned up in Qt 6. Any existing
QWS API documentation should be marked \internal.
Pick-to: 6.2 6.5 6.6
Task-number: QTBUG-35605
Change-Id: I24201406114feaf8af21403b09375a2ee9a4709e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
We should not export non-polymorophic classes wholesale. Only export
the non-inline functions instead.
There are no implicitly-declared special member functions in this
class that could cause problems, so we don't need to delay until Qt 7.
Pick-to: 6.6
Change-Id: I204d703498bf42465ea122d1f31c443ea439bd6e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I don't know why the compilers didn't shout here, but what _should_
have happened is:
- qSwap<quint64>() gets instantiated
- the unqualified swap() call inside gets resolved to std::swap()
- std::swap() is not constexpr in C++17, so qSwap<quint64>() silently
gets its constexpr dropped
- error, due to the use of non-constexpr function qSwap() in constexpr
function bswap()
There's no way through the function that doesn't hit the qSwap(), so
that is also not the explanation. And, indeed, replacing qSwap() with
std::swap() gets me the expected error...
Before compilers get the idea, rewrite the code to not require
swapping.
Amends 686c02224c.
Pick-to: 6.6
Change-Id: Ie1364bb2fd148bf995a8ffd321f77a6021176928
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
GCC 11 complains:
qprocess_unix.cpp:672:12: error: ‘char* strncpy(char*, const char*, size_t)’ specified bound 508 equals destination size [-Werror=stringop-truncation]
672 | strncpy(error.function, description, sizeof(error.function));
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
And it's correct: if description is longer than
sizeof(error.function), then error.function will not be
NUL-terminated.
While a quick check suggests that the user of the field performs a
qstrnlen(), thus avoiding falling off the unterminated end of
error.function, it's safer to always NUL-terminate. A single added
qDebug() << error.function would already be UB.
Fix by using _q_strncpy(), which is also more efficient, as it doesn't
write 0.5KiB of NULs in the likely case that description is short.
Amends 90bc0ad41f.
Change-Id: If5c2cb80fc4a3c92b8e78b680a635045bb14a30d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Apparently it is not enabled since the TLS backends became plugins,
which is unfortunate I wrote code in here that assumed it was.
Change-Id: I765435ce7d2c6fafa452d0453c705c27ff477be6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Shawn Rutledge
Volker Hilsheimer
Liang Qi
Thiago Macieira
Ahmad Samir
Tor Arne Vestbø
Mikolaj Boc
BogDan Vatra
Edward Welbourne
Friedemann Kleint
Laszlo Agocs
Tobias Koenig
Matthias Rauter
Axel Spoerl
Mårten Nordheim
Marc Mutz
Fabian Kosmale
Ilya Fedin
Colin Snover
Wladimir Leuschner
Amir Masoud Abdol
Topi Reinio
Richard Moe Gustavsen
Venugopal Shivashankar
Lorn Potter