RE: [boost] Filesystem Library mini-review

From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-12-13 11:42:04

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Beman Dawes
> Sent: 13 December 2002 15:31
> To: Boost mailing list; Boost mailing list
> Subject: Re: [boost] Filesystem Library mini-review
> 
> 
> 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.

And many unixes don't make them available without an environment
variable or an additional #define.

> 
> 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 strongly prefer the former. One of the first things I do when
having to deal with errno is map the errno names to something
readable like not_found_error. I can never remember the posix 
names and many unix programmers resort to the man page to look them 
up ( not caring if they are the posix names of the implementation 
ones.

> 
> 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.

Agreed. I've given a fair ammount of though to this over the past year
( whilst working on sockets). The conclusion I came to was that I would
rather have a standard C++ name on what ever platform I work on than
keep having to look them up on every platform. 

/ikh