Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk