[SSSD] Request for review of the new INI interface

Dmitri Pal dpal at redhat.com
Mon Dec 1 17:06:37 UTC 2014


On 12/01/2014 11:52 AM, Simo Sorce wrote:
> On Sun, 30 Nov 2014 22:15:01 -0500
> Dmitri Pal <dpal at redhat.com> wrote:
>
>>> 4. From an API standpoint it's not wise to use bytes as characters,
>>> e.g. |sep| should be a |wchar_t| (=uses current locale widechar
>>> representation, or |char32_t| from C1X, which is UTF32-encoded
>>> then, both |wchar_t| and |char32_t| use ASCII as basis so there is
>>> no actual conversion needed for now) below (not that the code is
>>> handling multibyte characters right now... but at least the API
>>> should anticipate this): -- snip -- int
>>> ini_config_add_str_arr_value(struct ini_cfgobj *ini_config, const
>>> char *section, const char *key, const char *value_str_arr[], size_t
>>> count_str, char sep, -- snip --
>> While I agree in general I think that requiring separators to be
>> ASCII characters in the value in an INI file is an acceptable
>> simplification. It is also defined in parsing that INI file can
>> contain separators that are ASCII characters.
> wchar_t is also completely deprecated and discourage, and should never
> be used anyway.
>
> Although you could perhaps get a string as separator (char *sep),
> rather than a single char.
> This way you could, in theory, use utf-8 multibyte chars, it also means
> some people may decide to use multiple chars as a separtor (like := ),
> not sure if this is a problem or an advantage.

This is not supported on the parsing side and I am not aware of any use 
case where it is actually needed.
I think making it a string would be really asking for trouble.

>
> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.




More information about the sssd-devel mailing list