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

[Thiago Macieira]

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