On 28/07/15 21:24, "Thiago Macieira" <thiago.macie...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
