[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