Mail Archives: djgpp-workers/2001/10/13/11:56:07
> > 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.
That's not what it does - there is no interrupt for this in DOS, and
_lfn_gen_short_name has code there that converts the string to upper
case and truncates it to 12 characters. If this is really a wrapper
for the Windows interrupt it should either fail on regular DOS or
return the string unchanged.
It also appears that in each of the 7 places this appears in the
library it is part of a strcmp with the long name - many of which are
not directly fncase related. Even more interesting is that in none of
those 7 places is the short name returned used at all except in
the string comparison. So this function is not actually used
anywhere in the library and each of these 7 places could be replaced
by an even simpler copy of what I provided - which just returns a
true or false flag if any characters would be changed.
> 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.
I'd be happy to remove use of strcmp _lfn_gen_short_fname, the short
name declarations and replace it with something else if that's what
we need to do. For example, if lfn=n we should always lower case
the names (a very simple test) instead of needing to generate a
string we strcmp with, throw away and then duplicate this behavior.
> 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.
Okay, let's step back for a second - my goal here (as show above) is not
to generate a perfect short lfn name - it's to determine if I need to
lowercase the name. Examples like IAMLOUD.EXE are simple. It gets
interesting when we have items like G++.EXE (which would NOT be lower
cased today, since the plus characters are not legal short chars). I
would argue that if all the alpha characters are upper case, and it's
in 8.3 format that we lowercase it - so we get g++.exe. I guess it
all depends on you opinion of why we are lowercasing at all.
Is it necessary to know about code page handling of characters to
decide if we downcase the entire string? I think that's an unneeded
complication - but I'm biased.
Win2K and XP do *NOT* support this windows interrupt. I think we
should try to make some effort to do the right thing in the default
configuration which lower cases many names. I'm open to solutions.
> 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.
Ok, we've shown that _lfn_gen_short_fname is so broken on Win2K and
XP that it is useless. I've shown we don't even use it's return
value. So, we keep it in the library, jump to the "dos" code if
2K/XP, and noone uses it? Trying to cling to an interrupt which
is only supported in a dead line of the operating system is bad news.
> 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?
No, but since it is unreliable, is used in 7 different places, we need
some way to fix this. I'd like something consistent between the
operating systems for something as simple (and relatively unimportant)
as what case short file names are returned in.
- Raw text -