This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v11 3/5] Abbreviated alternative month names (%Ob) also added (bug 10871).
On 01/11/2018 11:04 AM, Rafal Luzynski wrote:
> 11.01.2018 06:01 Carlos O'Donell <carlos@redhat.com> wrote:
>>
>>
>> On 01/08/2018 04:01 PM, Rafal Luzynski wrote:
>>> [...]
>>> * locale/langinfo.h: New public symbols _NL_ABALTMON_1,
>>> _NL_ABALTMON_2, _NL_ABALTMON_3, _NL_ABALTMON_4, _NL_ABALTMON_5,
>>> _NL_ABALTMON_6, _NL_ABALTMON_7, _NL_ABALTMON_8, _NL_ABALTMON_9,
>>> _NL_ABALTMON_10, _NL_ABALTMON_11, _NL_ABALTMON_12,
>>> _NL_WABALTMON_1, _NL_WABALTMON_2, _NL_WABALTMON_3, _NL_WABALTMON_4,
>>> _NL_WABALTMON_5, _NL_WABALTMON_6, _NL_WABALTMON_7, _NL_WABALTMON_8,
>>> _NL_WABALTMON_9, _NL_WABALTMON_10, _NL_WABALTMON_11, _NL_WABALTMON_12.
>>> [...]
>>
>> Why is there no ABALTMON_* via #ifdef __USE_GNU like there is for ALTMON_*?
>> It is OK without them, but seems like a missing useful feature.
>
> Short answer: the idea to define ABALTMON_* did not yet exist when
> I was implementing this. And even now I'm not sure this is the right
> moment to add this already.
>
> Long answer: the reason behind defining ALTMON_ via #ifdef __USE_GNU is
> that this standard already exists somewhere (in BSD and as accepted but
> not yet published future change in POSIX) but while it is not yet officially
> specified by POSIX we treat it as a GNU extension (hence #ifdef __USE_GNU)
> while __ALTMON_* symbols are defined unconditionally. But the idea of
> introducing abbreviated alternative month names to glibc is originally
> mine (although it already exists in other libraries, like ICU) and I did
> not think it would be standardized. So I have defined them as _NL_ABALTMON_*
> (as a forever private GNU extension). However, the idea has been filed
> as a POSIX update proposal only on October 27, 2017. [1] I don't think
> it will be accepted and published soon.
>
> So, do you guys want me to use a different naming pattern already?
Please keep the code as-is. Thank you for explaining the situation, it clarifies
the point. The code is OK to go in as-is.
>> OK with the test case changes to write UTF-8 directly in the test case string.
>
> A question about it below.
>
>> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
>
> I am going to publish another set of patches, mostly due to the changes
> in ChangeLog and commit messages. Does this Reviewed-by tag apply to the
> new patches as well?
Yes, it applies also to the new patches, as long as no substantive changes
are made to the code. I don't count the ChangeLog as being substantive.
>>> [...]
>>> +/* Some Cyrillic letters in UTF-8. */
>>> +#define CYR_n "\xd0\xbd"
>>> +#define CYR_o "\xd0\xbe"
>>> +#define CYR_ya "\xd1\x8f"
>>
>> Please encode the UTF-8 directly into the test case.
>>
>> Developers have to use UTF-8 capable editors, and fonts.
>
> A question about it below.
>
>>> [...]
>>> static const struct
>>> {
>>> const char *locale;
>>> @@ -57,6 +62,14 @@ static const struct
>>> { "pl_PL.UTF-8", "23 listopad 2017", "%d %B %Y", 4, 326, 10, 23 },
>>> /* The nominative case is incorrect here but it is parseable. */
>>> { "pl_PL.UTF-8", "24 listopad 2017", "%d %OB %Y", 5, 327, 10, 24 },
>>> + { "pl_PL.UTF-8", "25 lis 2017", "%d %Ob %Y", 6, 328, 10, 25 },
>>> + { "ru_RU.UTF-8", "26 " CYR_n CYR_o CYR_ya " 2017", "%d %b %Y",
>>> + 0, 329, 10, 26 },
>>
>
> Do I understand correctly, should I use lines like these?
>
> + /* ноя - pronounce: 'noya' - "Nov" (abbreviated "November") in Russian. */
> + { "ru_RU.UTF-8", "26 ноя 2017", "%d %b %Y", 0, 329, 10, 26 },
Yes, exactly like this.
> Regards,
>
> Rafal
>
>
> [1] https://sourceware.org/ml/libc-alpha/2017-10/msg01307.html
>
--
Cheers,
Carlos.