diff options
author | Marc Mutz <marc.mutz@qt.io> | 2023-02-16 23:09:47 +0100 |
---|---|---|
committer | Marc Mutz <marc.mutz@qt.io> | 2023-02-22 18:24:16 +0000 |
commit | 4a9e918d4ebdd9f7ea641e2b0f12a48c5f619acb (patch) | |
tree | fb29561558da6caa8502f2545fb79f3c4e758a25 /src/corelib/text | |
parent | 9f5a687ffebbc93ce5f8f25c544aa9129c6366c3 (diff) |
QMessagePattern: don't use strncpy()
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 be98fa32c7d56ea91359b647a329356fa44eca04.
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>
Diffstat (limited to 'src/corelib/text')
0 files changed, 0 insertions, 0 deletions