. . .
> who needs this? To do what?
Have you read Davd's mails? Everybody who has to implement fnmatch()
or regex() outside the libc needs it. . .
That hasn't been clear from your proposal. And this seems to be shifting
from the "problem" you felt existed. Namely, case-folded matching for
regular expressions.
. . .
> How do the APIs address this? Assume the sequence is defined
> in a case-mixed way, the APIs exist, and a program uses them
> to access the sequence. Now what?
Then the range will contain the upper/lowercase mixture. I've made
sure all the locale description I use are corrected.
If you can get the behavior you want by changing your localedefs,
you don't need APIs. You said the APIs address the issue of
case-folding in reg ex's. They don't; they merely let you find out
what the collation sequence is.
And I think it will be up to your users to determine whether your
locale descriptions are "corrected."
. . .
> First, the JTC1/SC22/WG20 Web site I've looked at says ISO 14651 is still
in
> the third FCD, not that it has been finalized. Either way, its status
> is irrelevant. . .
Not at all. And: the proposed solution does not depend on 14651. I
works with any locale description in the POSIX format.
You cited 14651 and its status as a "standard" as if that was
significant. I'm glad we agree it is not.
Anyway, I don't know what your problem is. If you want to handle it
differently, go on. . .
Sure, I'll handle it differently, and you're free to write whatever
you want in your own locales. My "problem" is that you were unhappy
with the internationalized range expression behavior, and so you've
proposed APIs to handle it. But they don't affect the behavior; they
only let you find out what it is. These are two different issues.
> However, if I look at the sequence in 14651 as an example, I see this:
> . . .
I know that the official locale description in the draft is not
following this. But it doesn't matter. You can easily rearrange the
lines without changing the collation order. Just put the entries with
<MIN> and <CAP> in separate blocks in the input. I've done this.
So again we agree that 14651 is irrelevant to this discussion. What
matters is how individuals write their localedefs.
-- Sandra
-----------------------
Sandra Martin O'Donnell
Compaq Computer Corporation
yyyyyyyyyyyyyyy@xxxxxxxxxx
yyyyyyyy@xxxxxxxxxxx
|