[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) |
Hello,
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
> !COMPILE_WIDE case?
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
workaround.
> 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,
Rafal
Re: Changes in nl_langinfo() and strftime() API in glibc, Bruno Haible, 2018/01/24