RFC: escape strings in KConfigBase

Thiago Macieira thiago at kde.org
Tue May 15 09:19:59 BST 2007


Olivier Goffart said:
> Le mardi 15 mai 2007, Andreas Hartmetz a écrit :
>> Hello list,
>>
>> I noticed that KConfigBase has some "forbidden" chars in certain fields,
>> quote:
>> "the '=' char is not allowed in keys and the ']' char is not allowed in
>> a
>> group name."
>> ...and another char, ',' by default, is also forbidden if you want to
>> use
>> the (very convenient) list read/write functions.
>> This is not state of the art, dangerous (who knows which strings happen
>> to
>> turn up in your config file), and cumbersome.
>
> I also already had the problem (in my case this was with ',' in lists)

Values should be obviously escaped. It makes no sense to restrict what
values we can save in our config files.

Keys, on the other hand (entry names and section names), I am not so sure.
If we can allow everything, that would be great, but I wouldn't want the
code to become too complex or incompatible with existing installations
just to provide that.

You don't save user strings in keys. If your program is doing that, I
submit that you should redesign it.

>> I can come up with three possible solutions:
>> - Auto-escape all strings, using the backslash notation if nothing
>> better
>> (i.e. faster to parse and still human readable) exists.
>> - Provide an escape function that takes the chars to escape as a
>> parameter
>> - Add Escape/NoEscape as flags to the write/read functions.
>
> I vote for automatic escape using backslash notation.
>
> I don't see any case where you wouldn't want to escape.

I am not sure backslash escaping is the best solution. But I'll leave that
to whomever actually writes the code.

One point, though, is that we should strive to retain compatibility with
other installations. Any escaping done must take that into consideration.

Remember that our config files share the same INI format as desktop files
and those are quite strict. If we change our config format, we have to be
careful not to propagate any side-effects to desktop files. (where
side-effects = incompatible format changes)

What's more, there's KDE 3 compatibility to keep in mind. For one thing,
we'll be reading KDE 3 config files for a while, even if we update it on
save. For another, some of the config files we write will be read by KDE 3
applications (think kdeglobals).

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358






More information about the kde-core-devel mailing list