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

[Joshua Phillips]

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 <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.
>
>
>
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tinycc-devel

signature.asc
Description: This is a digitally signed message part.