This is the mail archive of the libc-locales@sourceware.org mailing list for the GNU libc locales 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: localedef: inconsistent handling of "copy" keyword


Hi,

On 2016-04-20 10:49, Mike Frysinger wrote:
> POSIX is pretty clear when it comes to the "copy" keyword in a category:
> for every one, it always says:
> 	Specify the name of an existing locale which shall be used as the
> 	definition of this category. If this keyword is specified, no other
> 	keyword shall be specified.
> 
> the provided grammar is also pretty unambigious (this is LC_CTYPE, but
> all the others look the same):
> lc_ctype            : ctype_hdr ctype_keywords         ctype_tlr
>                     | ctype_hdr 'copy' locale_name EOL ctype_tlr
>                     ;
> ctype_hdr           : 'LC_CTYPE' EOL
>                     ;
> ctype_tlr           : 'END' 'LC_CTYPE' EOL
>                     ;
> 
> basically, POSIX says that if you have a copy, that's it:
> LC_CTYPE
> copy "foo"
> END LC_CTYPE
> 
> if you try to use any other keywords, it should be rejected.  however,
> this isn't how our localedef behaves.  for LC_CTYPE & LC_COLLATE, it
> allows for copy to be intermingled with other keywords.  this is good
> as it means we get to cut down on a ton of duplicate content.  this is
> bad in that it seems to be a violation of the spec ... i'm not seeing
> where this behavior is permitted.
> 
> the reason i ask is that this same scenario comes up with other locale
> categories: it'd be nice to share content more, but localedef rejects
> things.  it comes up whenever you have a category that mixes language
> and territory details ... if you have another locale w/the same script
> in the same locale, it'd be nice to not duplicate things.  examples:

Agreed that spec looks clear that if copy is used, then no other
keywords should be accepted. But I'm not sure what the rationale for
this is, as you say there seems to be clear benefits allowing copy with
other keywords. Perhaps this could be checked with the Austin Group (or
even request a change to allow this by the spec as well)?

Thanks,

-- 
Marko Myllynen


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