Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-07-24 20:05:56

At 11:21 AM 7/23/2003, Erkki Seppala wrote:

>As this behavior (handling certain characters differently on systems
>that can handle them) seems to be a designed feature, I must raise my
>concern that I really don't want to see a generation of unix-programs
>that fail to handle some files I have in my hd. The program above
>would seem to me to be perfectly portable even if had the ability to
>handle all kinds of characters in filenames. (I wouldn't want to
>resort to using some depreciated native-interfaces to accomplish that

The native interface isn't intended to be deprecated. It has many valid
uses, such as for handling operator input supplied paths.

>And answering to Vladimir Prus on the bug report: I would hate to see
>a program that was not able to create, manipulate and unlink certain
>files, just for the sake that some other platforms have problems with
>those characters. Handling files called ' ', '"*?' isn't a problem for
>me. I have almost a 1000 files with character : (perl manual-pages)
>and some with letters < and >.. (think message-id's)

It sounds to me as if you are dealing with many files with names that you
do not expect to be portable even to POSIX systems, let alone portable to
completely unrelated operating systems. (I say that because the POSIX
portable filenames are limited to 0-9, a-z, A-Z, '.', '_', and '-'.)

If so, what is the interest in a portable library? Why not just use the
native API available for your operating system?

That being said, there is a long-standing issue as far as existing files
go. The native names should be supported for existing files even if they
are not likely to be portable. This works currently to some extent, but not
as fully as it could and should.

>(Btw, why is this a library-issue at all anyway? I'm sure the
>operating system is more than pleased to tell the program that the
>filename is invalid.)

There are two kinds of portability; syntactic portability and semantic
portability. Semantic portability implies that not only the form of library
calls is portable (syntactic portability), but also the behavior. Syntactic
portability without semantic portability provides only an illusion of

It's a complex issue, but the intent of the filesystem library is that the
default should be for behavior that is as portable as reasonably possible
without requiring heroic efforts on the part of implementors.

Thanks for the comments,


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