From: "Sandra O'donnell USG" <yyyyyyyy@xxxxxxxxxxx>
Date: Wed, 16 Aug 2000 13:18:06 -0400
> who needs this? To do what?
Everybody who has to implement fnmatch() or regex() outside the
libc needs it.
That hasn't been clear from your proposal.
I'd like to second Ulrich Drepper's and David Korn's mail. The
functionality is needed for any application that needs to match
compatibly with fnmatch and regex. There are many reasons why the
implementation's versions of fnmatch and regex might not suffice:
e.g., the implementation might not support a needed extension, or it
might be too slow, or it might not work well with threads or with
signals.
And this seems to be shifting from the "problem" you felt
existed. Namely, case-folded matching for regular expressions.
The problems are related. For example, GNU grep currently mishandles
"[a-z]" in locales where the string "A" sorts next to "a", but where
the collating element "A" falls next to "B". This is because GNU grep
cannot access the collating elements.
Whatever one's position on the case-folded matching controversy, it is
clear that a user application should be able to behave compatibly with
the locale. If the locale specifies case-sensitive matching, that is
what user apps should do. As things stand, this isn't practical for
many popular user apps.
If you can get the behavior you want by changing your localedefs,
you don't need APIs.
Applications should work in all locales. As the maintainer of GNU tar
I shouldn't have to tell my users to change their localedefs to work
around the inadequacies of the API. tar should be compatible with
whatever localedefs the user or implementer supplies.
|