Date: Sat, 13 Oct 2001 10:52:09 +0200 From: "Eli Zaretskii" 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 Precedence: bulk > 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).