[Development] Asking for a FF exception for ICU based QStringConverter

Fabian Kosmale fabian.kosmale at qt.io
Wed Jun 8 16:17:29 CEST 2022


unfortunately, we did not manage to get a QStringConverter backend based on ICU into Qt in time for FF
(https://codereview.qt-project.org/c/qt/qtbase/+/393373). This is a feature strongly requested by KDE as an enabler
for their KDE Frameworks 6 port [1] and from various users in APAC, where non-UTF codecs like Shift JIS  still have some

What remains to be done:
- There are concerns that mixing Qt versions might lead to an unbounded memory leak with the current implementation.
  I don't think that's actually the case (but if it is, then we need a different enough approach that this most likely has to be
  deferred to Qt 6.5 at least).
-  Testing uncovered that there's an issue with writing out replacement characters, causing infinite recursion under certain
    circumstances. That needs to be fixed, but should hopefully be easy by checking and mirroring how ICU's own replacement
    callback works.
- Thiago (rightfully) requested more test cases; I'm cautiously optimistic that those won't uncover any further issues.

Impact on other parts of Qt and 6.4 API review
- The base patch will not introduce any new public API, it just extends what is possible with the existing API.
- The follow-up patch will introduce one new function; and make use of the new ICU backend in a few places in Qt, which
   before would have rejected the incoming data.

Expected additionally needed time:
I expect that the remaining work can be completed by the end of next week.

Given the above, would it be possible to grant a feature freeze exemption until end of next week for this feature?


[1] KDE has to support legacy codecs in e.g. their text editor(s).

More information about the Development mailing list