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

List:       kde-core-devel
Subject:    Re: KConfigGroup read/write bug for QByteArray
From:       Thiago Macieira <thiago () kde ! org>
Date:       2007-09-17 6:39:29
Message-ID: 200709170839.48157.thiago () kde ! org
[Download RAW message or body]


Matt Rogers wrote:
>On Sunday 16 September 2007 20:39, David Jarvie wrote:
>> On Sunday 16 September 2007 14:41:28 Matt Rogers wrote:
>> > On Sunday 16 September 2007 07:41, David Jarvie wrote:
>> > > Using KConfigGroup::writeEntry() to write a QByteArray and then
>> > > KConfigGroup::readEntry() to read it back in again can result in a
>> > > value which is different from the original value, because the
>> > > value written to the config file is converted to UTF8 when it is
>> > > read back, so that all byte values >= 0x7F are changed to
>> > > multi-byte values.
>> > >
>> > > If this is the desired behaviour (which I doubt), it's difficult
>> > > to convert back from UTF8 since calling QString::fromUtf8
>> > > truncates the value as soon as it encounters a null byte. In data
>> > > arrays, null bytes are common.
>> >
>> > Can you provide a patch? Then we can discuss your proposal based on
>> > the technical merits of it rather than just sitting in our chairs
>> > wondering to ourselves how it would actually work and whether or not
>> > we'd like it.
>>
>> It turns out that the bug actually lies in KConfigGroup::writeEntry(),
>> and that all that is required is for a QByteArray not to be converted
>> to UTF8 before being written. I attach a patch to fix it, and to add a
>> test case to the unit test.
>
>Looks fine to me. I think this can be committed.

Makes sense to me too. The lowest level should be a QByteArray, since 
KConfig is supposed to store binary data.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    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]