Re: [PATCH] localedef: check LC_IDENTIFICATION.category values

[keld at keldix dot com]

On Thu, Apr 14, 2016 at 09:50:33AM -0400, Mike Frysinger wrote:
> On 14 Apr 2016 11:26, keld@keldix.com wrote:
> > Actually the standards 14652/30112 were set up so you could declare
> > what version of the locale category was used for the data.
> > POSIX is different from 14652 and again different from 30112.
> > 30112 is the one that most closely corresponds to glibc implementations.
> 
> in general, for standards that are stuck behind ISO's dumb paywall (they
> want to charge CHF198 for the pleasure of downloading what should be in
> the public), you'll have to tell me what values to plug in, and/or what
> it says.

I agree.

> although i have found this link:
> 	http://www.open-std.org/JTC1/SC35/WG5/docs/30112d10.pdf
> is that the same ?

It is a new Working Draft for the revision of 30112, so it contains all of
the approved TR 30112 from 2014, plus some. But it is not a standard,
it is work in progress. That is why we are allowed to have it publically available.

> if it is, i would highlight that the examples provided in the spec do
> not seem to line up with the spec itself ;).  the Danish example that
> is embedded in the file tries to use "i18n:2000", and it doesn't use
> double quotes like it says it should be.

There are errors everywhere. This is a draft, and not supposed to be error-free.
Anyway, the same inconsistency was probably in the approved TR.
I will see to that this be corrected. Probably it should be marked with
the new standards's identifying value.

> > I also think that POSIX allows for more categories than the ones that the
> > 9945 standard defines, and in that way 14652 and 30112 are compatible 
> 
> looks like ISO 9945 is just the combined POSIX standard (2003 edition).
> the public 2004 edition [1] and 2013 edition [2] do not define the cat
> LC_IDENTIFICATION, so they wouldn't have anything to say here.  also,
> even if those allow for defining of arbitrary categories, that's kind
> of orthogonal to glibc's localedef needs isn't it ?  the utility has
> been rejecting all unknown categories for basically ever at this point.
> [1] http://pubs.opengroup.org/onlinepubs/009695399/
> [2] http://pubs.opengroup.org/onlinepubs/9699919799/

Well, yes, LC_IDENTIFICATION is a novelty of 14652. 
But 9945 - POSIX does allow implementation defined categories AFAIK.
There is one new category in 30112, namely LC_KEYBOARD. I am not sure whether
glibc supports LC_XLITERATE eitherC, or the functionality is present only in 
LC_CTYPE.

> 
> if you try to do:
> LC_FOO
> ...
> END LC_FOO
> localdef will reject it as a syntax error.
> 
> if you try to do:
> LC_IDENTIFICATION
> ...
> category "en_US:2000";LC_FOO
> ...
> END LC_IDENTIFICATION
> localdef will reject it as a syntax error (ignoring the standard part).
> 
> are you referring to something else ?

No. I would like your last example to not error, it could issue a warning,
or at least that LC_KEYBOARD be accepted. 
In that way one could use localedef to test new functionality.

> > with POSIX. I would advise that this still be allowed, but then declared
> > in the LC_IDENTIFICATION section. Maybe we should use a specifiv version value like
> > "non-standard" to indicate that.
> 
> why do we need to support that ?  we're talking about what localedef
> will accept, and localedef is entirely a glibc-specific utility.  the
> binary format it produces is internal glibc ABI.  seems like accepting
> other random values isn't useful to us.

Localedef is specified in POSIX, 
http://pubs.opengroup.org/onlinepubs/009696699/utilities/localedef.html

> > I would advice to use the values for the locale versions
> > given in 30112. The values defined in 30112 are:
> > i18n:2004
> > i18n:2012
> > posix:1993
> 
> OK.  shall i update all the locale files then to use i18n:2012 ?

Yes, I think that this is the most appropiate.

Best regards
Keld