Like with other such changes, this both fixes a Coverity complaint about using a char32_t as a char32_t[], and improves readability. Unlike the already-ported users, this one is a bit non-standard, and deserves a bit of explanation: The code uses an optimization whereby it only attempts to decode the UTF-16 surrogate pair if the UTF-8 side wasn't an ASCII character. It therefore had split the operation QUtf8Functions::nextUcs4FromUtf8() performs into the read of the first byte, followed by the ASCII check, and a call to fromUtf8() only if no ASCII was found. We can still use QUtf8Functions::nextUcs4FromUtf8() here, because a) QChar::ReplacementCharacter is non-ASCII and b) an ASCII character never produces a decoding error in nextUcs4FromUtf8(). We can therefore drag the ASCII-check "behind the fromUtf8() call", yielding the same sequence of operations that nextUcs4FromUtf8() performs. Amends 274e07a339ebedddd8b3366342ebde3cbfb9536a. Pick-to: 6.10 6.9 6.8 Coverity-Id: 403749 Change-Id: Ia444885135fac26af98d078a2a28052e7241856e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>