Subject: NetBSD master CVS tree commits
To: None <Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU>
From: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
List: tech-kern
Date: 02/08/1996 16:15:11
   From: Chris_G_Demetriou@NIAGARA.NECTAR.CS.CMU.EDU
   X-Copyright: Copyright 1995, Christopher G. Demetriou.  All rights reserved.
   X-Notice: Duplication and redistribution prohibited without consent of
	     the author.
   Date: Wed, 07 Feb 96 13:47:55 EST
   Sender: owner-tech-kern@NetBSD.ORG
   Precedence: list
   X-Loop: tech-kern@NetBSD.ORG

   > christos
   > Tue Feb  6 16:22:03 EST 1996
   > Update of /a/cvsroot/src/sys/lib/libkern
   > In directory pain.lcs.mit.edu:/b/tmp/cvs-serv3818
   > 
   > Added Files:
   > 	strncasecmp.c 
   > Log Message:
   > Add strncasecmp.c; extracted from ADOSFS adlookup.c.

   It's not clear that this is appropriate.

Hm, for ADOSFS it is even more complicated (somebody should fix this
some year in case it is not implemented :-).

There are 3 version of ADOSFS, each comes in an US flavour (only ASCII
upper case characters are mapped to lower case for comparison and
before hash value computation) and in an "international" (in reality,
Latin1) flavour (all ISO-8859-1 characters are mapped to their lower
case equivalents). This is not meant to be dependent on the user's
selected locale.

   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

I second this.

	   (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.)

Yes.

   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...)

Yes. This will happen on mounted Intl. Amiga-FFS. You won't even find
the right file, in the first place, due to the wrong hashing function.

Regards,
	Ignatio Souvatzis