This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Fix problem with trailing slashes in include paths on mingw
Joern RENNECKE <joern.rennecke@st.com> 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
distinguish.
>> 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)
>> c--;
>> if (c == path+1 && ISALPHA (path[0]) && path[1] == ':')
>> c++;
>> if (c[1] == '/')
>> c[1] = '\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)
c--;
if (c == path+2
&& ISALPHA (path[0]) && path[1] == ':' && path[2] == '/')
c++;
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[2] == '/'' to the if condition, which I think takes
care of this case.
zw