tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.


From: lostgallifreyan
Subject: Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.
Date: Tue, 14 Apr 2009 16:07:38 +0100

Actually I made a horrible howler that you didn't spot. :) I never noticed it 
till I tried passing two files to compile just now. TCC went into a silent 
CPU-consuming spin, I think because my test for lowercase called the 
case-forcing loop for *every character* found in that first loop until a 
lowercase one was found. I had it right before I posted that first attempt at a 
patch, but had tried to reduce it, and reduced it too far. The earlier one used 
a flag variable. It definitely works as advertised, even for multiple files.


#ifdef _WIN32
            /* Set W9X DOS 8.3 upper case paths to lower case. */
            unsigned char *p;
            int flag = 1;
            if (r[1] == ':' && r[2] == '\\') {
                for (p = r; *p; p++)
                    if (flag && *p != toupper(*p))
                        flag = 0;
                if (flag == 1)
                    for (p = r; *p; p++)
                        *p = tolower(*p);
            }
#endif



Also, when you mention the distinction in Windows for case sensitive 
extensions, you know it can't exist, at least for the same file name in the 
same location... So when it comes to .s and .S, I don't know what to do. That's 
why I won't over-ride expected behaviour if someone wants a command line 
written accordingly, they just make sure (if using Windows) that the 
commandline has a lower case letter on the path as written (or a forward slash 
after the colon). I described this clearly already.

What I have considered is using GetLongFileName() in Kernel32.dll to pass long 
names as specified in the file system. It's a neat answer but only for W98, no 
good in W95 (and I think redundant in W2K and WXP). Another thing is to add 
some other option for assembler code files, such as .asm (or .ASM, same thing) 
for those requiring preprocessing in Windows, and .s (or .S) to be converted in 
DOS shortname paths so TCC makes the usual interpretation of .s NOT being 
preprocessed. But I don't know ASM, it's not my call what decision gets made 
there, and GCC doesn't recognise the extension ASM anyway. For now, if I were 
to try assembler code I'd just watch carefully what was put into my .s (or .S) 
files, and make batch scripts with the right extension case for TCC.

To summarise, the various interpretations of case sensitive extensions is a 
minefield the moment you use a file system that does not recognise case 
sensitivity. I think the best that can be done is to make sure that DOS 
shortname paths do at least work most of the time, using a method that makes it 
easy to pass written arguments to TCC with case-based determinations that work 
regardless of what case they have in the file system. So that's why I wrote the 
patch as I did, to cleanly solve one small, specific problem.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]