[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: Thiago Macieira <thiago () kde ! org>
Date: 2010-02-08 12:15:25
Message-ID: 201002081315.26367.thiago () kde ! org
[Download RAW message or body]
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?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic