Re: RFA: Fix problem with trailing slashes in include paths on mingw

[Zack Weinberg <zack at codesourcery dot com>]

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