This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 14 Apr 2016 17:04, keld@keldix.com wrote:
> On Thu, Apr 14, 2016 at 09:50:33AM -0400, Mike Frysinger wrote:
> > On 14 Apr 2016 11:26, keld@keldix.com wrote:
> > > 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.

sure -- see below

> 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.

we don't support LC_KEYBOARD or LC_XLITERATE today.  i think any new
categories would need to be proposed including why glibc should carry
them at all.  i haven't read the standard, so i can't speak to either.

> > 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.

we can have it warn.  localedef has precedence w/not warning about many
things or being fatal by default, but adding -v makes it more strict.
this seems to fall into that bucket.

i'm not keen on -v/--verbose being a hidden alias to also "exit non-zero
in many more cases", but that's a diff topic :).

> > > 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

on the frontend sure.  i was thinking of its output format which is not
specified by POSIX but is an internal glibc ABI detail.  it even says:
	The localedef utility shall convert source definitions for locale
	categories into a format usable by the functions and utilities ...
i.e. it doesn't specify that output format.

back to the frontend, what POSIX specifically says is:
	In addition, the input may contain source for implementation-defined
	categories.

so glibc's localedef is free to support as many more or few categories as
it sees fit.  that includes outright rejecting unknown ones.

also, if we want to speak stricly about POSIX, it also says:
	-u  code_set_name
	Specify the name of a codeset used as the target mapping of character
	symbols and collating element symbols whose encoding values are defined
	in terms of the ISO/IEC 10646-1:2000 standard position constant values.

pretty sure that says we aren't even permitted to support a newer standard
there.  whether it matters in practice i'm not sure (haven't done a diff on
the diff versions/standards).
-mike

Attachment: signature.asc
Description: Digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]