Date:	Sat, 13 Oct 2001 10:52:09 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	sandmann AT clio DOT rice DOT edu
Message-Id:	<6048-Sat13Oct2001105207+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC:	djgpp-workers AT delorie DOT com, tim DOT van DOT holder AT pandora DOT be, acottrel AT ihug DOT com DOT au
In-reply-to:	<10110130452.AA20729@clio.rice.edu> (sandmann@clio.rice.edu)
Subject:	Re: W2K/XP fncase [was Re: New perl package]
References:	<10110130452 DOT AA20729 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Fri, 12 Oct 2001 23:52:27 -0500 (CDT)
> 
> > That assumes we actually know how 71A8h works, which is what we need
> > to duplicate.  I have some idea about that, but since it's nowehere
> > documented, I cannot say if it's 100% true, since I never tested my
> > hypothesis on too many files.
> 
> I think you are getting too worried about a broken Windows interrupt
> here.  We use it merely to compare the name to the original file 
> component to see if they are identical (including case).  If they 
> are, we then lower case the name.

No, _lfn_gen_short_fname is the direct interface to the Windows
interrupt.  It does not exist merely to downcase file names when we
think we should.

So if you want to change all the places that call it by some other
code, that other code should not be called _lfn_gen_short_fname, it
should be a new function.

> Attached is an example which provides almost identical behavior to
> the windows version (and I believe will behave completely identical
> when used with fncase stuff).  Tech-trivia: it handles spaces and
> multiple periods a bit differently, but in those cases we want to
> leave the name alone anyway.

As far as the FNCASE-related code, I think your function behaves
identically, with the single exception: the handling of 8-bit
characters is something that changes according to the installed
locale/codepage; what you saw is probably correct only for the US.  I
don't know how to handle this in a table-driven code, unless we want
to put there a separate table for every codepage.

But in the 7-bit area this code is sufficiently different from what
71A8h does, so it cannot replace _lfn_gen_short_fname in general.

I'm still puzzled why a global non-trivial change is deemed better
than something localized to a specific OS in an otherwise proven
function.  The current support for LFN-related features took several
releases to get right; do we really want to put that at jeopardy for
the sake of saving a few cycles?  The one complaint about DJGPP I did
_not_ hear is that it was slow (except for when stat is called
heavily, which is not the case here).

- Raw text -