> On Nov. 30, 2013, 1:45 a.m., Thomas Lübking wrote:
> > kcontrol/krdb/krdb.cpp, line 102
> > <http://git.reviewboard.kde.org/r/114219/diff/1/?file=221836#file221836line102>
> >
> >     QFile::encodeName() seems equal to QString::toLocal8Bit(), 
> > ::decodeName() to ::fromLocal8Bit()
> >     
> >     I don't think one can just drop one of them and whether transcoding is 
> > required probably depends on what is done to the string interim.
> >     
> >     If at all "KToolInvocation::klauncher()->setLaunchEnv()" would perform 
> > a second decode, so it probaly depends on what that does.
> >     
> >     Was "locale charmap" determined by the reporter in the bug?
> >     
> >     ---
> >     
> >     Secret world domination plan:
> >     ------------------------------
> >     #1: classified
> >     #2: classified
> >     #3: force ASCII as global standard
> >     #4: classified
> >     #5: classified
> >     #6: classified
> >     #7: classified
> >     #8: classified
> >     #9: classified
> >     #a: classified
> 
> Yichao Yu wrote:
>     encodeName/toLocal8Bit is used to encode a unicode string to a 
> c-string/byte-array representation and decodeName/fromLocal8Bit does the 
> reverse.
>     
>     The proper decoding is already done in QFile::decodeName above and the 
> QString already has the right unicode string in it.
>     
>     Basically, QString is not a wrapper of arbitrary c-string/byte-array, 
> rather a wrapper of a unicode string so whatever done to a QString before or 
> after should assume it is a valid unicode string and is independent of what 
> encoding (utf8 in the case of dbus) is needed afterward.
>     
>     Encode to a byte array and cast it back can only cause wrong encoding in 
> the second conversion and will not affect what is done in setLaunchEnv.
>
> 
> Yichao Yu wrote:
>     Or in another word QString has no encoding (well, by which I mean the 
> internal encoding is trasparent to the user), only byte array and c-string 
> has encoding.
>
> 
> Thomas Lübking wrote:
>     QString(QByteArray) according to the API doc actually differs between Qt4 
> & 5 (fromAscii -> fromUtf8) but an encoding should not happen nevertheless 
> because:
>     
>     282 void KLauncher::setLaunchEnv(const QString &name, const QString 
> &value)
>     283 {
>     284 #ifndef USE_KPROCESS_FOR_KIOSLAVES
>     285    klauncher_header request_header;
>     286    QByteArray requestData;
>     287    
> requestData.append(name.toLocal8Bit()).append('\0').append(value.toLocal8Bit()).append('\0');
>     
>     Also QString(QByteArray) is obvisouly problematic by itself for the 
> apparent 4/5 "incompatibility".
> 
> Yichao Yu wrote:
>     I guess you can also put it in this this way (setLaunchEnv have 
> toLocal8Bit inside) although I still think the simplest way is to remember 
> QString -- encode --> QByteArray, QByteArray -- decode --> QString and always 
> to the necessary explicit conversion.
>     
>     That's why I hate hate hate this constructor. (and I've already fixed 3-4 
> bugs in KDE due to this constructor.) It might actually be helpful to compile 
> KDE with it commented out and replace everything with explicit conversion.....
>
> 
> Yichao Yu wrote:
>     I guess you can also put it in this this way (setLaunchEnv have 
> toLocal8Bit inside) although I still think the simplest way is to remember 
> QString -- encode --> QByteArray, QByteArray -- decode --> QString and always 
> to the necessary explicit conversion.
>     
>     That's why I hate hate hate this constructor. (and I've already fixed 3-4 
> bugs in KDE due to this constructor.) It might actually be helpful to compile 
> KDE with it commented out and replace everything with explicit conversion.....
>
> 
> Yichao Yu wrote:
>     I guess you can also put it in this this way (setLaunchEnv have 
> toLocal8Bit inside) although I still think the simplest way is to remember 
> QString -- encode --> QByteArray, QByteArray -- decode --> QString and always 
> to the necessary explicit conversion.
>     
>     That's why I hate hate hate this constructor. (and I've already fixed 3-4 
> bugs in KDE due to this constructor.) It might actually be helpful to compile 
> KDE with it commented out and replace everything with explicit conversion.....
>
> 
> Yichao Yu wrote:
>     ahh.... sth wrong with my network.... sorry for the duplicated post...

I just had a look at the history of the specific line of code and tracked it 
back to "This commit was manufactured by cvs2svn" (238ffd07).

The original line was:
QCString value = QFile::encodeName(list.join(":"));

doing several porting conversions via at one step QByteArray to finally 
QString. Given that it used to be a QByteArray the ::encodeName seems 
reasonable, but since it's QString I think that it's save to drop it.


- Martin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114219/#review44857
-----------------------------------------------------------


On Nov. 30, 2013, 5:38 a.m., Yichao Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114219/
> -----------------------------------------------------------
> 
> (Updated Nov. 30, 2013, 5:38 a.m.)
> 
> 
> Review request for kde-workspace, David Faure, Martin Gräßlin, and Hugo 
> Pereira Da Costa.
> 
> 
> Bugs: 327919
>     http://bugs.kde.org/show_bug.cgi?id=327919
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> -------
> 
> list.join already returns a QString and there is no need to encode it and 
> cast back to QString again....
> 
> P.S. for a patch that applies to both KDE4 and KF5(master for kde-workspace, 
> frameworks for kdelibs?) How should I submit review request? Should I add 
> both in branch or submit two review request? (But often the patch cannot 
> apply directly due to context or file path changes).
> 
> 
> Diffs
> -----
> 
>   kcontrol/krdb/krdb.cpp 92d84e9 
> 
> Diff: http://git.reviewboard.kde.org/r/114219/diff/
> 
> 
> Testing
> -------
> 
> Compiles.
> Fixes the problem here.
> 
> 
> Thanks,
> 
> Yichao Yu
> 
>

Reply via email to