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

Volker Krause vkrause at kde.org
Thu Jun 9 17:52:58 CEST 2022

On Thursday, 9 June 2022 11:36:21 CEST Giuseppe D'Angelo via Development 
> Il 09/06/22 01:48, Thiago Macieira ha scritto:
> > d) Because if this, code using QStringConverter with non-builtin encodings
> > will leak resources unless it's recompiled for 6.4. No source changes are
> > necessary.
> > 
> > I am saying that (d) is an acceptable situation because of (a) and (b),
> > and in spite of (c).
> So basically this is a soft ABI break?
> Code currently using QStringConverter on a non-UTF encoding is failing
> (but not leaking anything). Same code with an upgraded Qt will work, but
> will leak memory (how much? once per QStringConverter object? once per
> encoding?); a recompilation is needed to stop the leak.
> I'm not really sure how much QStringConverter is used _directly_ by 
> client code, but a random search shows that the number is not zero:
> > https://lxr.kde.org/ident?v=kf5-qt5&_i=QStringConverter&_remember=1

[replying for KDE here]

All uses of QStringConverter in KDE's code are in so far unreleased Qt6 code 
paths, so the above mentioned uses are no problem either way. As Fabian 
mentioned, KDE's Framework 6 release is blocked on this work, so that's also 
not going to change.

> I'm also concerned that this won't pass Alpha review without adding more
> APIs around. How exactly do I set a QStringEncoder/Decoder with a custom
> encoding on top of a QTextStream, QSettings, etc.?

While not ideal, this is something one can work around. That's much harder to 
do for the entire lack of non-UTF codecs.
> With these two concerns combined, I'm close to -1 this idea.
> (I'm perfectly fine with adding a (Qt-private) way for the XML classes
> to deal with non-UTF encodings, but that's not sufficient, is it?)

Private API wouldn't help KDE's use-case, for internal use we have QTextCodec 
in Qt5CoreCompat as well, but neither one is suitable for use in public API.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220609/0fe8c4a6/attachment.sig>

More information about the Development mailing list