Re: [boost] Filesystem Library mini-review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-12-13 10:30:38

At 08:19 AM 12/13/2002, Peter Dimov wrote:

 >From: "Beman Dawes" <bdawes_at_[hidden]>
 >>
 >> Part of the problem is that there is no guarantee that the macros will 
be
 >> available in <cerrno>.
 >
 >Yes, that's true in theory, but in practice, is there a platform that
 >doesn't have the macros in <cerrno>?

It is messier than that.  For example, Microsoft supplies cerrno with only 
some of the macros. EBUSY, ENOTDIR, ENOTEMPTY, and others are missing.

The filesystem library also needs one or two additional codes for its own 
errors.

 >Note that there are two issues here. First, whether the portable error 
code
 >reported by the library matches the numeric value of the corresponding 
EXXX
 >macro. Second, how does the exception.hpp header make the constants
 >available, i.e. does it #include <cerrno> (with <cerrno> guaranteed to 
have
 >the macros), or does it provide its own aliases.

The "already standard" argument you make below pushes toward including 
<cerrno>. Yet usual C++ practice would be more like the enum in the current 
header, and not including <cerrno>.

Would you see any value in providing aliases with names that map more 
closely to the POSIX names?

For example, instead of:

       not_found_error,
       not_directory_error,

Would you prefer:

       enoent,
       enotdir,

If so, why?

I'm wondering if part of your worries could be caused by the lack of a 
filesystem function similar to POSIX perror()?

 >> That's messy for Boost; we would have to provide
 >> our own and configure accordingly.
 >
 >Depends on whether we target a platform where <cerrno> doesn't have the
 >macros. Do we?
 >
 >> It might also be messy for
 >> standardization; its seems to have a lot of trouble when multiple
 >> committees start specifying the contents of the same header.
 >
 >On the other hand, ignoring other well established standards isn't a good
 >thing either, from standardization point of view.
 >
 >> The final
 >> worry about a POSIX based scheme is that it might mislead users into
 >> thinking every operating system can deliver exactly the POSIX errors 
and
 >no
 >> others. That isn't the case.
 >
 >I don't see the problem. Any kind of a portable error scheme can mislead
 >users into thinking that all OSes report the same set of errors (and in
 >general, any portable API can mislead users into thinking that all OSes
 >support the same functionality.) We already have a standard portable 
error
 >scheme. Why reinvent the wheel? Will we do any better?

We might. The POSIX errno scheme doesn't seem all that strong to me.

Your arguments are all reasonable, but I'm still not seeing beyond the 
disadvantages of trying to interpret the POSIX approach in C++. Do you have 
a firm proposal?

--Beman