On Feb 7,  1:47pm, Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU (Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU) wrote:
-- Subject: Re: NetBSD master CVS tree commits

| It's not clear that this is appropriate.
| 
| In particlar, different file systems have different heuristics as to
| what "toupper()" and "tolower()" of certain characters is, and they're
| certainly different than the one used by 'C', or in ASCII.
| 
| It seems to me that there are two ways to go here:
| 	(1) each file system which is case-insensitive should have its
| 	    own comparison routine, that mimics the native OS's
| 	    definition of case mappings for 'weird' characters, or
| 	(2) if there is one 'global' comparison routine, it should
| 	    understand different locales, etc., so that people can
| 	    at least set what they think is the appropriate
| 	    translation.
| 
| it seems to me that using one 'standard' strncasecmp is both
| US-centric, and _wrong_.  (The latter, because it doesn't properly
| mimic what the native file system would do to deal with case
| comparison.)
| 
| I don't really think that it's possible or reasonable to make the
| kernel understand locales, but i _do_ think that if you're going to
| mimic support for case-insensitive file names, you should at least use
| the same lower<->upper mappings that the native file system used.
| (if you don't, then it seems to me that data files on those file
| systems which reference other files on those file systems could
| possibly not end up talking about the right files...)

I am not sure what is the best solution either. I was just trying to
get the kernel routines that appeared to be using c library functions
to use a standard one instead of rolling their own. I agree with you 
about the locale issues, but so far the file system code is us centric.
So what is better? Let the filesystem code use a single strncasecmp,
or let each filesystem roll their own? In reality the majority of
filesystems are developed in the states anyway?

christo