> On 22 Jan 2026, at 02:25, Thiago Macieira <[email protected]> wrote:
>
> On Wednesday, 21 January 2026 15:17:50 Pacific Standard Time Albert Astals
> Cid
> wrote:
>> We have found a garbage string that when passed to QTextDocument makes it
>> assert
>
> Code in question is this:
>
> const bool isSurrogate = c.isHighSurrogate() && i < length - 1;
> const char32_t ucs4 = isSurrogate
> ? QChar::surrogateToUcs4(c, string[++i])
> : c.unicode();
> const QUnicodeTables::Properties *p = QUnicodeTables::properties(ucs4);
>
> It doesn't verify that the code unit after the high surrogate is a low
> surrogate. That must be why it ended up with a UTF-32 code unit outside of
> the
> Unicode range.
>
> This could be fixed in QTextEngine. But I would argue that passing corrupted
> UTF-16 to any Qt API outside of QString itself is the bug.
I'd argue that Qt should not crash on invalid UTF16 in any case. There are only
a handful of places where we use QChar::surrogateToUcs4() in Qt, those should
be made safe IMO. Or fix surrogateToUcs4() to return the object replacement
character in case the values are out of range.
Cheers,
Lars
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
