diff options
| author | Marc Mutz <marc.mutz@qt.io> | 2023-03-02 19:05:16 +0100 |
|---|---|---|
| committer | Marc Mutz <marc.mutz@qt.io> | 2023-03-17 00:41:32 +0100 |
| commit | c19f9716fb06a0bff26ec3f2c5104b60e6cd245a (patch) | |
| tree | 557199d970b71fdab93d8b8bd65ae65fee70a9d4 /tests/auto/sql/kernel/qsqldatabase/tst_qsqldatabase.cpp | |
| parent | 6a6e9337c763163597ab3ee2a3d25a07ea54fb60 (diff) | |
QMessageAuthenticationCode: port to QByteArrayView [3/3]: static hash()
The class is not used frequently enough to warrant the overhead of a
Q_WEAK_ QByteArray overload to fix the SiC Type A for users that pass
objects that implicitly convert to QByteArray, esp. since we'd need
_four_ overloads to handle the two byte array arguments here, and
still cause ambiguities, because there's only one level of "weakness"
in Q_WEAK_OVERLOAD, but we'd need two. QCryptographicHash::hash()
also doesn't have it.
[ChangeLog][QtCore][QMessageAuthenticationCode] The constructor,
setKey(), addData() methods as well as the static hash() function take
arguments by QByteArrayView instead of QByteArray now.
[ChangeLog][Potentially Source-Incompatible Changes] More APIs now
take QByteArrayView instead of QByteArray. You will now get a compile
error when your code passes to such functions objects that implicitly
convert to QByteArray, but not QByteArrayView. Wrapping such arguments
in QByteArray{~~~} to make the cast explicit is a backwards-compatible
way to avoid this problem.
Fixes: QTBUG-111676
Change-Id: Iaff832df3b315ca2eee7bff93720b6681182036f
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>
Diffstat (limited to 'tests/auto/sql/kernel/qsqldatabase/tst_qsqldatabase.cpp')
0 files changed, 0 insertions, 0 deletions
