From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74519 invoked by alias); 14 Apr 2016 15:04:21 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 74499 invoked by uid 89); 14 Apr 2016 15:04:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Draft, pleasure, charge, advise X-HELO: www.open-std.org Date: Thu, 14 Apr 2016 15:04:00 -0000 From: keld@keldix.com To: libc-alpha@sourceware.org, carlos@redhat.com Subject: Re: [PATCH] localedef: check LC_IDENTIFICATION.category values Message-ID: <20160414150407.GB1849@www5.open-std.org> References: <570E96AE.3070209@redhat.com> <1460587532-5278-1-git-send-email-vapier@gentoo.org> <20160414085919.GA19618@www5.open-std.org> <20160414092626.GB19618@www5.open-std.org> <20160414134344.GC6588@vapier.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160414134344.GC6588@vapier.lan> User-Agent: Mutt/1.4.2.2i X-SW-Source: 2016-04/txt/msg00359.txt.bz2 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