Re: [Tinycc-devel] Re: TCC:cannot find -l"xyz.dll"

[lostgallifreyan]

Joshua Phillips <address@hidden> wrote:
(08/04/2009 17:56)

>Firstly, strupper isn't a C function, and I can't find anything about it in my 
>manpages.
>

Strange.. I'm probably half-remembering an earlier version of Lua's current 
string.upper() C will do what I need though, somehow. I'll find it when I'm 
ready to to look.

>Secondly, passing a filename to a program - the OS shouldn't interpret program 
>arguments, so if you run "tcc foo.c", even if foo.c is actually called FOO.C, 
>tcc should still recognise it as a C file, try to open it, and *then* the OS 
>will match "foo.c" with the upper-case "FOO.C". I don't see this as a problem 
>(if anything, it's a problem with case-preserving, case-insensitive file 
>systems ;) but if you want to push a fix, the mob branch is open to all.
>

In the case of switches the OS leaves well alone, just passes as ordered, but 
in W9X, the file system uses short 8.3 convention AND long names. But when 
passing to the command line via drag/drop it chooses the shortname paths 
format. Windows seems arbitray in these things, it does this for other methods 
too, and I don't know how much control I can place on it. I assume none because 
if I do anything that's meant to run on another system I won't try to control 
that system, only my own code's response to what it finds. So I'm left with two 
choices, I either will have to read the longname for whatever file the OS 
passes, no matter how it passes it, or just make sure that the test on a name 
isn't case sensitive. Second case is easiest, and makes sense in Windows 
because if you tried to put x.c and x.C in same dir, one would overwrite the 
other, so no valid distinction needs to be preserved here.

Re that last point, the question will be whether compatibility with Win32 is 
considered a higher priority than preserving a distinction between .c and .C 
files. My guess is that in the end, if put to a wide test, the Win32 
compatibility would win because it's easier to adopt toe other, clearer 
distinctions alreay used. I won't push for a fix other than raising the point 
here though. it might have precedent elsewhere, but I have my fix, and if I'm 
the only person urging it on others, it's best I limit that to a clear 
statement somewhere that gets archived, and I've already done that now. If 
other find they agree, then it might go further with or without my help.