This is the mail archive of the
mailing list for the GCC project.
Re: RFA: Fix problem with trailing slashes in include paths on mingw
Joern RENNECKE <firstname.lastname@example.org> writes:
> Zack Weinberg wrote:
>>Okay, so how's this for the comment?
>> /* The native stat() on NT4 accepts trailing slashes, but not
>> backslashes. Cygwin's stat on Windows 2000/XP doesn't accept
>> either trailing slashes or backslashes. (C:/ and C:\ are of
>> course fine, but C:\\ and C:// are not.) It is harmless to
> No, C:\\ and C:// work too (on the machine I'm testing YMMV with a
> different MS Windows flavour.) It's // and \\ which don't work.
I misunderstood what you said, then. In that case we shouldn't say
they don't work in the comment, but it seems pointless to try to
>> remove trailing slashes on systems that do accept them, so we
>> do it unconditionally. */
>>And this for the code (after the existing slash canonicalizer):
>> while (*c == '/' && c > path)
>> if (c == path+1 && ISALPHA (path) && path == ':')
>> if (c == '/')
>> c = '\0';
> No, that won't work.
> - The slash canonicalizer leaves c pointing at the terminating zero.
Oops. Okay, in that case
while (c[-1] == '/' && c > path+1)
if (c == path+2
&& ISALPHA (path) && path == ':' && path == '/')
if (*c == '/')
*c = '\0';
which is even a little clearer, since c now points to the trailing
slashes (after the while loop), instead of the character before them.
> - When you have gobbled away indicriminatively all trailing slashes,
> and find that you are left with a drive designator, you can't
> blindly assume that there was a trailing slash. The path might be
> "C:", followed in memory by some other datum (probably malloc
> administration information) that happens to start with '/'.
I added '&& path == '/'' to the if condition, which I think takes
care of this case.