[boost] [filesystem] Generic path grammar corner cases

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-02 07:56:55

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