[boost] Re: [filesystem] Generic path grammar corner cases

From: David Daeschler (daveregs_at_[hidden])
Date: 2005-06-02 08:37:53

Since the slash or slashes in that case are extraneous, I would also say 
option 2 is the way to go.  Remove the trailing slash because it was 
probably not intended in the first place.

The only question I would have is about the path that is simply "//" or 
natively in the windows world "\\".  In the windows command prompt changing 
to those two directories yields the following results.

C:\Documents and Settings\blah>cd \\
'\\'
CMD does not support UNC paths as current directories.

and

C:\Documents and Settings\blah>cd \

C:\>

So if you were to trim the trailing slash in "//", it could potentially have 
different results in windows since it sees the "\\" as the beginning of a 
UNC path.

Or I could just be looking to far into it, and this isn't a problem at all?

- Dave

"Beman Dawes" <bdawes_at_[hidden]> wrote in message 
news:d7mvgn$jnu$1_at_sea.gmane.org...
> I'm working to align the Boost.Filesystem generic path grammar with the 
> POSIX specification. Doing so clarifies the specification of the library, 
> and ensures that all native paths for both POSIX and Windows will work 
> correctly. (Windows follows the POSIX conventions in some of the corner 
> cases involved.)
>
> The particular cases involve extra slashes in paths. For example, 
> "/foo//bar//". I was surprised to find that such a path is well-defined 
> for POSIX and Windows, with a meaning of "/foo/bar/." In other words, 
> multiple slashes treated as a single slash, and paths with a trailing 
> slash treated as if a period was appended. The rules for more than two 
> leading slashes are a bit more complex - for POSIX they are treated as a 
> single slash, for Windows that is an invalid path.
>
> Question: what should path("foo//bar//").string() yield?
>
> 1) "foo//bar//"
> 2) "foo/bar/"
> 3) "foo/bar/."
>
> (1) follows the rule that the path string is always exactly as input. 
> Desirable in that if a platform actually implements something a bit 
> different from the POSIX specs for multiple slashes, implementations will 
> behave as expected for the platform. Downside is much more complex 
> implementation (because many more functions have to be able to cope with 
> multiple slashes) and more complex testing.
>
> (2) Desirable in that if a platform actually implements something a bit 
> different from the POSIX (and Windows) specs for multiple slashes, 
> implementations will behave portably and correctly in a POSIX (and 
> Windows) sense.
>
> (3) Desirable in that for all three options directory iteration will 
> return three elements - "foo", "bar", "." - so it is a bit counter 
> intuitive for the "." not to appear in the string() results. Not a strong 
> argument.
>
> I'm leaning toward (2). Any comments?
>
> --Beman
>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>