Re: [PATCH] Use Unicode code points for country_isbn

[Joseph Myers <joseph at codesourcery dot com>]

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
joseph@codesourcery.com