On 12/01/2014 11:52 AM, Simo Sorce wrote:
On Sun, 30 Nov 2014 22:15:01 -0500
Dmitri Pal <dpal(a)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.