Re: [boost] Filesystem Library mini-review

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-12-13 11:11:50

From: "Beman Dawes" <bdawes_at_[hidden]>
> 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.

I see EBUSY (16), ENOTDIR (20), ENOTEMPTY (41) in errno.h in both VC6 and
VC7(.1).

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

This is an interesting problem; we'll have to get back to it. :-)

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

The question for me is not whether exception.hpp includes <cerrno>, but
whether it defines the E... macros. An enum in the current header is good
enough, although providing two different naming schemes for the same error
codes must be justified by more than "we don't like <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?

You haven't addressed an important question, is not_found_error/enoent equal
to ENOENT? If it is, enoent obviously wins over not_found_error as otherwise
people need to maintain a mental map. In a perfect world users will never
leave the filesystem sandbox so this doesn't really matter; but this is
rarely the case in real code that typically needs to go outside the C++
standard in order to do something useful.

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

No. I have expressed my stance on functions that return
implementation-defined strings in the past. ;-) BTW, aren't perror/strerror
standard C and hence C++?

My preferred approach to obtain a human-readable error message is to get
"ENOENT" returned from exception::what(); I know what to do with it (see
attachment). But this is a side issue.

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

But we don't need to interpret anything. POSIX has already done the work for
us. :-)

My proposal is

- portable error codes returned by the filesystem library shall have the
same meaning as the corresponding E*** macro, if one exists. In particular,
std::strerror(), or an equivalent (the user may already have a fully
localized replacement) should produce the right error message.

- exception.hpp shall make the E*** macros available (whether it does so by
including <cerrno> is unspecified.)

  (alternatively, it might offer another naming scheme, although I don't see
the point in that.)

Note that the second bullet can be rejected independently of the first.