[Development] QT_NO_CAST_FROM_ASCII for platformsupport

[Thiago Macieira]

On terça-feira, 14 de fevereiro de 2012 15.03.34, Olivier Goffart wrote:
> On Tuesday 14 February 2012 13:50:06 Johannes Zellner wrote:
> > Hi,
> > 
> > what is the reason for " DEFINES += QT_NO_CAST_FROM_ASCII "
> > in the platformsupport.pro file?
> > 
> > I just hit that and would like to understand why we have this
> > inconvenience here.
> 
> Ok, i don't know the specific on why it is there in platform support. The
> rest of Qt just has QT_ASCII_CAST_WARNINGS

Actually, there are many parts of Qt with QT_NO_CAST_FROM_ASCII:

$ git grep QT_NO_CAST_FROM_ASCII -- mkspecs src/\*.pr? | cat
src/platformsupport/platformsupport.pro:DEFINES += QT_NO_CAST_FROM_ASCII
src/plugins/platforms/windows/windows.pro:DEFINES *= QT_NO_CAST_FROM_ASCII
src/plugins/sqldrivers/qsqldriverbase.pri:DEFINES += QT_NO_CAST_TO_ASCII 
QT_NO_CAST_FROM_ASCII
src/sql/sql.pro:DEFINES += QT_NO_CAST_FROM_ASCII
src/testlib/testlib.pro:    QT_NO_CAST_FROM_ASCII \
src/tools/bootstrap/bootstrap.pri:        QT_NO_CAST_FROM_ASCII \
src/tools/bootstrap/bootstrap.pro:        QT_NO_CAST_FROM_ASCII \

Having it enabled is a good reason because:

> Anyway, casting from char* to QString must be avoided on library code.
> 
> the reason:
> 
> if you have
> 
> QString foo = file.readAll();
> 
> This compile fine, and even look right, but might be wrong.
> because a char* do not say anything about the encoding. Is it latin1, utf8,
> other?
> 
> So Qt provide QTextCodec::codecForCString.

Not for long :-)

http://codereview.qt-project.org/14626


> There is also QTextCodec::codecForLocale used by QString::fromLocal8Bit.
> 
> For example, in a french programing team, you would have
> label->setText("Résultats Erronés");
> And this will probably be in latin1, because the file is saved as such on
> the disc. (and latin1 is faster than utf8).

And they'll have to recode their sources to UTF-8 with Qt 5, or add the 
wrapping QLatin1String.

> So if in your library you do
> QString foo = file.readAll();
> The result will depends on the application.

With Qt 5, it will not. It will be decoded using UTF-8, which is good and bad:

Good: because it's well-defined and you know what will happen.

Bad: because if you have binary data, UTF-8 cannot decode it. ISO-8859 can 
decode anything to Unicode, so it's idempotent in a round-trip. UTF-8 isn't, 
so if you mix QString and QByteArray by mistake, you might cause data 
corruption.

> So the rule is:
>  - Always be explicit about which encoding you import the string from.
>  - If it is a literal, use QStringLiteral in 95% of the case, and
> QLatin1String in most of th	e other cases.

We need to document when to use either.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120214/aa157407/attachment.sig>