[Development] FW: Backwards compatibiltiy break in Qt 5.5

Knoll Lars Lars.Knoll at theqtcompany.com
Fri Jul 31 09:20:00 CEST 2015


On 28/07/15 21:24, "Thiago Macieira" <thiago.macieira at intel.com> wrote:

>On Tuesday 28 July 2015 21:58:08 NIkolai Marchenko wrote:
>> Fact is : you are severly overestimating the amount of cases where
>> homoglyph is a problem at the same time severly underestimating the
>>amount
>> of code you broke and inconvenience caused by the change.
>> The amount of people that has since agreed with my point of view in this
>> thread is a testament to that.
>> Want homoglyph  debugging? turn on environment variable. Simple as
>>that. At
>> the same time peopel with existing code won't be tearing at their hair
>>on
>> the prospect of retyping every qdebug instance
>
>I don't think I am underestimating the annoyance to those people nor that
>I am 
>overestimating the benefit. You have also take into account that a great
>majority of source code is written in English and for those cases this
>feature 
>is a net win.
>
>Anyway, I'm waiting for Lars to make a decision.
>
>Lars, you can either make your choices below or you may request consensus
>and 
>then make your decision:
>
>1) qDebug for QStrings should
>  a) escape everything non-US-ASCII (5.5.0 behaviour)
>  b) escape everything that isn't QChar::isPrint
>  c) escape only US-ASCII control characters (0 to 31), backslash and
>quote
>  d) escape only NUL, backslash and quote
>  e) escape nothing (5.0 through 5.4 behaviour)
>  [I haven't included option f) mangle irrevocably (4.x behaviour)]

I think (b) is the most sane option (including escaping of backslash and
quote). 

If you’re worried about isPrint performance, feel free to optimise the
ascii (or latin1) case. In practice, I don’t think this will matter
currently, as qDebug is using QTextStream behind the scenes anyway.

>
>2) ditto for qDebug for QByteArrays, except that for:
>  b1) escape everything that isn't isprint() from ctype.h (locale
>dependent)
>  b2) escape everything that isn't printable under Latin 1
>  Note that QByteArray::toUpper and toLower do not and have never used
>ctype.h   
>  and are instead fixed to Latin 1.

QByteArray should probably use (a), as the encoding isn’t clear (we’re
unfortunately not really consistent in our usage neither. Constructing a
QString from a QByteArray assumes utf8, toUpper/toLower as you say assumes
latin1).

>
>3) QtTest should
>  a) follow qDebug and be consistent
>  b) do it differently, in which case we need to select which of the
>options 
>      Above

Are there arguments against being consistent? Apart from us not wanting to
change it in 5.5.1?
>
>4) when to apply those changes, which are technically behaviour changes
>  a) 5.5.1
>  b) 5.6.0

5.5.1 has my vote. Yes, we’re changing behaviour once again, but this
brings it a lot closer to 5.4, while avoiding most of the issues that
initially triggered the change.
>
>Note that the QtTest QString change happened in 5.4.0, so I advise
>against 
>changing QTest::toString(QString) in 5.5.1, if a change is to happen.

Agree. 
>
>Obviously my preference has already been stated. If we eliminate 1a, my
>preferences are: 1c and 2a. I do not want QChar::isPrint to be used
>because 
>it's expensive.

As said above, I don’t think it matters, especially if we inline the ascii
(and maybe latin1) case.
>
>Anything except 1e will still change "C:\Users" to "C:\\Users" in the
>output, 
>which was one of the complaints listed.

Yes, but this is unavoidable. We need to escape non printable characters
and quote, and this implies we also need to escape the backslash. My goal
is to keep the string easily readable in all languages, which is what IMO
is needed to make debugging and logging easy.

Cheers,
Lars





More information about the Development mailing list