[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [Kde-pim] Fwd: Re: KDE 4.4.98 (4.4 RC3)
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2010-02-08 19:15:51
Message-ID: 201002081915.51573.aacid () kde ! org
[Download RAW message or body]

A Dilluns, 8 de febrer de 2010, Thiago Macieira va escriure:
> Em Domingo 7. Fevereiro 2010, ās 16.33.34, argonel escreveu:
> > On Sun, Feb 7, 2010 at 3:58 AM, Thiago Macieira <thiago@kde.org> wrote:
> > > The protection has to happen somewhere. Technically, it's
> > > Konversation's fault
> > > for passing unfiltered network data into an API.
> > >
> > > But it could also be a QString issue, for allowing those invalid UTF-8
> > > strings
> > > to be converted to UTF-16 in the first place.
> > >
> > > Note that changing the D-Bus behaviour may likely introduce bugs in
> > > Glib-based
> > > applications, where conversions from UTF-8 do implement this check.
> > > (Which, in
> > > my opinion, is incomplete)
> >
> > If you're referring to dbus's lack of checks for 0x1FFFE and so on, I
> > found that I was unable to create a QChar > 0xFFFF, so perhaps not
> > checking those is reasonable.
> 
> Of course you can't create a QChar > 0xFFFF.
> 
> But QString can handle UTF-16 surrogate pairs and does it just fine. The
> sequence 0xD83F 0xDFFF is the U+1FFFF non-character.
> 
> The question is: should those be allowed to exist in a QString? (I think
>  the answer is yes)
> 
> Should QString::toUtf8 and fromUtf8 accept those?
> 

From what i understand, they are not valid UTF-8 (just valid UTF-16) so i 
think the obvious (from the i have no idea of what i'm talking about position) 
is saying "No".

Albert

[prev in list] [next in list] [prev in thread] [next in thread]