diff options
author | Marc Mutz <marc.mutz@qt.io> | 2021-12-09 22:22:04 +0100 |
---|---|---|
committer | Marc Mutz <marc.mutz@qt.io> | 2021-12-10 06:42:49 +0100 |
commit | 0800947d7d2127eacaabf66ee1702d4980897041 (patch) | |
tree | 67931acf58cd4a200d4b07aa73352f559b7cdf89 /examples/widgets/widgets/tablet | |
parent | f917b0d4b9784e554852d65b48216e0c2fe426bd (diff) |
QVarLengthArray: fix UB (precondition violation) in range-erase()
When the range-erase() function is called with an empty, valid range,
it passed equal iterators to both the first and the last arguments of
std::move(f, l, d) (the algorithm, not the cast). This is UB, since it
violates the algorithm's precondition that d ∉ [f,l). For non-empty
ranges, f > d, thus d < f, hence d ∉ [f,l), so everything is ok
_there_.
Fix the empty range case by returning early.
Reviewers may question the precondition, expecting that std::move(f,
l, f) just be a no-op, but the algorithm, as specified, performs
self-move-assignments in that case, which need not be supported. In
fact, the Hinnant criterion, itself only applicable if one calls for
self-swap-safety, asks for self-move-assignment-safety only for
objects in the moved-from state. QVarLengthArray, itself, meets only
the Hinnant criterion; self-move-assignment of non-empty QVLAs invokes
UB.
So, the UB here is real.
Qt 5.15 uses std::copy() here, which has the same precondition as
std::move(), and the same fix applies there, too.
[ChangeLog][QtCore][QVarLengthArray] Fixed a bug where range-erase()
could invoke undefined behavior when called with an empty range.
Pick-to: 6.2 5.15
Change-Id: I656aa09d025168d6d9ef088ad4c6954d216f0d54
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'examples/widgets/widgets/tablet')
0 files changed, 0 insertions, 0 deletions