Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-18 15:21:05

At 10:59 AM 8/18/2003, David Abrahams wrote:

>Beman Dawes <bdawes_at_[hidden]> writes:
>> Yes. Plus there are some other issues.
>> The actual interface would include boost::filesystem::path
>> constructors which take an additional argument to explicitly specify a
>> name checker function. In working out use cases, it seems that
>> temporary overrides of the default function are best handled via these
>> constructors. That leaves only the case of wishing to permanently
>> replace the default function, and the simpler approach you are talking
>> about would be better for that.
>> For safety, such a set_legal_name_policy() would use the
>> write-once-before-read idiom to avoid a dangerous global
>> variable. (I'm actually thinking of "name_check" for the type, and
>> "set_name_check" for the function name.)
>> I'm about to post a message asking for opinions on the details of the
>> policy function pointer or object.
>This starts to align with what I've been thinking. Every path object
>could maintain a chain of checkers, and combinations of path objects
>(e.g. via operator/) would use the union of the checkers of their
>components, so that checking would never become less-restrictive

That is more machinery than is needed. It would be a nice design for a
system that had to revisit elements, but for that isn't required here.

When I was first working with designs for error checking, I tried a lot of
similar schemes. Eventually I realized that treating name validity as an
invariant established at construction was much simpler and performed quite
well. It doesn't require keeping a chain of checkers. It performs the
checking at the point in the calling program where knowledge of what is
valid is present.

> Of course, though I think this goes against the grain of
>the library, I believe the default checker should always be the for
>the native platform.

Because the native platform may support several different file systems
within the same directory tree, it isn't possible to perform a full and
correct lexical (inspection of the name only) check for the native
platform. You in effect have to try the path and see if the operating
system accepts it. What the lexical level name check done by class path is
trying to do is early detection of gross naming errors.

A specific example might help. Say you are working on a Linux platform. It
supports a really wide range of characters in names. But you know the code
sometimes will run on Windows, so you would like to check automatically
that some directory tree you create doesn't violate Windows naming
conventions. You do this by specifying a Windows name checker (which
disallows a bunch of special characters). This will prevent your program
from inadvertently using the special characters that Windows always

Now when the program actually runs on a Windows box, a native path may be
given (say by operator input) as the root, and then the relative portions
your program adds get tacked on. If the operator supplied root happens to
be a CD ISO-9660 file system, your carefully chosen relative names may
fail, because the ISO-9660 names are way more restricted that general
Windows names.

In that case, the attempt at early detection was a failure; the name
checker did no good. But a lot of real-world errors will be detected early,
so I don't see the name checking as a failure. It just is a partial check,
not an iron-clad guarantee. A useful axillary mechanism, but not the main

But because it can't be an iron-clad guarantee, I'd prefer not to build an
even mildly complex mechanism to support it. Particularly since some
programmers will disable it anyhow.


Boost list run by bdawes at, gregod at, cpdaniel at, john at