This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
Re: [PATCH] Use Unicode code points for country_isbn
- From: Florian Weimer <fweimer at redhat dot com>
- To: keld at keldix dot com
- Cc: Marko Myllynen <myllynen at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, libc-locales at sourceware dot org
- Date: Tue, 21 Jul 2015 11:05:11 +0200
- Subject: Re: [PATCH] Use Unicode code points for country_isbn
- Authentication-results: sourceware.org; auth=none
- References: <5571B8C2 dot 8000108 at redhat dot com> <20150609071130 dot GA26925 at domone> <5576BC13 dot 5020001 at redhat dot com> <20150721081840 dot GE12267 at vapier> <20150721084006 dot GB29742 at www5 dot open-std dot org> <55AE08BD dot 5020703 at redhat dot com> <20150721090239 dot GA31441 at www5 dot open-std dot org>
On 07/21/2015 11:02 AM, keld@keldix.com wrote:
> On Tue, Jul 21, 2015 at 10:54:21AM +0200, Florian Weimer wrote:
>> On 07/21/2015 10:40 AM, keld@keldix.com wrote:
>>
>>> The use of Unicode points helps making the locales portable, eg.
>>> when crosscompiling for different architectures, including embedded systems, ebcdic
>>> systems, utf-16 systems and utf8 systems, when you are on a different host platform.
>>
>> Is this really a relevant use case? Cross-compiling glibc to an EBCDIC
>> system?
>
> I also mentioned other cases, which may be more relevant..
I can't see how. Unless someone maintains this code and processing
pipeline, it's not going to work with the current code. Is anyone doing
it? I doubt it.
We don't use trigraphs in C sources, so I really don't get why we have
to use an equivalent construct in the locale definitions. Unless the
goal is to raise the bar for new contributors for some reason, but I
think the project has long walked away from that approach.
--
Florian Weimer / Red Hat Product Security