This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use Unicode code points for country_isbn
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Keld Simonsen <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: Fri, 24 Jul 2015 15:11:15 +0000
- 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> <20150721092217 dot GG12267 at vapier> <20150721115852 dot GA24115 at rap dot rap dot dk> <alpine dot DEB dot 2 dot 10 dot 1507221719420 dot 21570 at digraph dot polyomino dot org dot uk> <20150722190228 dot GA18489 at www5 dot open-std dot org> <alpine dot DEB dot 2 dot 10 dot 1507221951100 dot 19567 at digraph dot polyomino dot org dot uk> <20150724104349 dot GC10515 at rap dot rap dot dk>
On Fri, 24 Jul 2015, Keld Simonsen wrote:
> > Because glibc makes particular implementation choices in areas that are
> > implementation-defined. It's an implementation, not a meta-implementation
> > that tries to cover the range of permitted implementation choices.
> > Meta-implementations (at least of the language part of ISO C) exist, but
> > they exist in the field of formal systems used to reason about C programs.
> I am also active in C standardization. I think it is a good goal to not
> deviate and restrict an implementalton more than necessary. And at least
> not restrict it further than already implemented. That would lead to a loss
> of functionality.
The point of things being implementation-defined is to allow
implementations flexibility in what is convenient for those
implementations. glibc duly uses that flexibility to adopt particular
choices for implementation-defined behavior (some depending on the
architecture, but most being globally fixed for all glibc configurations,
so that all glibc code is free to rely on those choices).
> I thought cygwin was a GNU implementation for windows, and that it also
> implemented glibc. I now understand that the cygwin libc is different from
> glibc. But how different? Do they use glibc locales, or are they able to?
I don't think there's any use of glibc locales by newlib as Cygwin's libc.
> I would like the glibc locales to also be usable in other libc environments.
> Most of all because they IMHO are the most comprehensive set of locales available.
> So that would benefit users also outside glibc. Why not have this in mind
> also for our project?
I think CLDR is more likely to be the most comprehensive set of locales
(it certainly claims to be "the largest and most extensive standard
repository of locale data available"), and unlike glibc's locales is
intended for wider use. Even if we did want wider use for glibc's locales
(beyond use by glibc's locale-dependent functions after having been
compiled into binary form by glibc's localedef program from the same
version of glibc) I think we should still say: UTF-8 is the way of the
present and future, other multibyte character sets are legacy. And, just
as we require a range of GNU tools to build glibc, so we can rely on
features of one part of the GNU system when working on another part, so we
should require GNU localedef to build glibc's locales.
> > I'd rather have some extension to allow a locale source file to declare
> > that it is in UTF-8, and then use UTF-8 throughout except for control
> > characters or combining characters used in isolation.
> That would make it difficult to maintain in environments that is not using utf8.
It would make the locales easier to maintain for people using UTF-8, the
number of which (among people concerned with i18n) can be presumed to be
much greater than the number using legacy character sets.
Joseph S. Myers