[Development] FW: Backwards compatibiltiy break in Qt 5.5

[Thiago Macieira]

On Friday 31 July 2015 07:20:00 Knoll Lars wrote:
> >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.

No optimisation because, as this thread has shown, non-ASCII text is common. 
Therefore, optimising for a particular case is not necessary and might just 
hurt the whole scenario. Besides, it's *debugging*, which implies slow code 
anyway. I'd rather make this simpler.

> >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).

Ok, so no change for QByteArray.

> >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?

Same as before: we're trying to figure out why two strings are not the same. 
I'd rather *see* the evidence than try to guess.

> >
> >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.

Ok.

> >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.

Ok.

I will try to submit a patch tomorrow.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center