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).
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?
> 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?
> > [...]
> > +/* 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 },
Regards,
Rafal
[1] https://sourceware.org/ml/libc-alpha/2017-10/msg01307.html