Drag-and-drop? O_o For case-insensitive comparisons in C, there's strcasecmp (GNU) and stricmp (MSVCRT). They're both identical in function, but are non-standard extensions.
On Wednesday 08 April 2009 17:26:37 lostgallifreyan wrote: > Joshua Phillips <jp.sittingd...@gmail.com> 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. > > > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/tinycc-devel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
