On Wednesday, 8 June 2022 10:10:20 PDT Giuseppe D'Angelo via Development wrote: > > To be clear for everyone: this can happen (depending on where we introduce > > the new API) if some code is using QStringConverter with codec names that > > it currently doesn't support. This is likely to be very limited, because > > that code is currently not working (it always produces an invalid > > encoder/decoder). That probably means it's blind porting from QTextCodec > > which did support more codecs. The fix is to simply recompile. > > Could you please elaborate a bit? What does "mixing Qt versions" mean in > the above?
a) QStringConverter is new in 6.0, therefore there's not much "legacy" code b) QStringConverter has a constructor taking a codec by name. If it wasn't one of the Unicode transforms, Latin 1 (by one of its names) or "System", it currently fails and returns a converter that does not convert c) Because it's meant as a replacement to QTextCodec, there's a possibility that code ported to Qt 6 is using this constructor with non-builtin encodings (and simply gives up, instead of producing corrupt data or crashing) The current code proposal makes this constructor work and return a valid converter that converts. However, because ICU requires resources, we needed to add a destructor to the class that currently is trivially destructible 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). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
