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

Giuseppe D'Angelo giuseppe.dangelo at kdab.com
Thu Jun 9 11:36:21 CEST 2022

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

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.?

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?)

My 2 c,
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4244 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220609/d49a3589/attachment.bin>

More information about the Development mailing list