[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes in nl_langinfo() and strftime() API in glibc

From: Rafal Luzynski
Subject: Re: Changes in nl_langinfo() and strftime() API in glibc
Date: Tue, 30 Jan 2018 23:11:56 +0100 (CET)


Sorry for this late response, I was focused on more urgent tasks.

23.01.2018 09:47 Paul Eggert <address@hidden> wrote:
> [...]
> PS. This doesn't matter for Gnulib, but why define ABALTMON_1 only for the

This is only to make sure that NLW() macro works as expected.
In !COMPILE_WIDE case it just outputs its argument without any
change.  So NLW(ABDAY_1) will be ABDAY_1, NLW(MON_1) will be MON_1
and so on.  In COMPILE_WIDE case it prepends _NL_W to the argument
so NLW(ABDAY_1) will be _NL_WABDAY_1, NLW(MON_1) will be _NL_WMON_1
and so on.  For the abbreviated alternative month names we need
_NL_ABALTMON_1 and _NL_WABALTMON_1.  If we passed _NL_ABALTMON_1
directly it would make _NL_ABALTMON_1 in !COMPILE_WIDE case (correct)
and _NL_W_NL_ABALTMON_1 in COMPILE_WIDE (incorrect).  So I've decided
to use NLW(ABALTMON_1) which in COMPILE_WIDE case generates
_NL_WABALTMON_1 (correct) and in !COMPILE_WIDE I define ABALTMON_1
as _NL_ABALTMON_1 so NLW() generates ABALMON_1 which is actually
_NL_ABALTMON_1.  Again correct.

It would be easier if ABALTMON_1 (and all ABALTMON_*) was defined
officially which I hope happens one day but for now this simple

> Not that anyone ever uses the wide code....

AFAIK it's commonly used on Windows platform.  I guess this is a good
target if Gnulib is supposed to provide the GNU API on non-GNU platforms.

Thank you for your support.  Best regards,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]