"Sandra O'donnell USG" <yyyyyyyy@xxxxxxxxxxx> writes:
> Are you one of those who might use this interface?
No. I'm writing the libc and have access to the internal data
structures.
> If so, would you expect to produce significantly different output
> for your regular expressions than is typical for users of POSIX
> internationalized OSes?
I don't know. All the Unices we have (means all of them) are crippled
by being the US-only version. We don't pay extra to get the language
extensions and therefore I have no idea what other OSes do.
> I'm asking because I remember you were concerned about the existing
> behavior of internationalized reg ex's, because you didn't want
> (among other things) case-folding. That is, you didn't want a
> range like [a-c] to match
>
> a A b B c
Right. And this is addressed meanhwile by using this kind of
information.
> So the APIs will use the order of the lines in the LC_COLLATE section.
> How, if at all, does the end result differ from what users get with
> existing POSIX locales and existing regular expression implementations?
> Will collation *order* and collation *sequence* truly be different
> things? Will there be any localedef syntax changes?
No localedef syntax changes. I'm just emitting another table. And
yes, the order and the sequence are very different. Look at the
LC_COLLATE specification in ISO 14651 (which is actually a standard)
> There are no interfaces for directly retrieving information in other
> parts of the locale. For example, there are no APIs for getting the
> info in the LC_CTYPE section.
Sure there is. You can call the is*() and to*() functions for each
and every character.
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
|