[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ignoring EOPNOTSUPP and ENOTTY
From: |
Bruno Haible |
Subject: |
Re: ignoring EOPNOTSUPP and ENOTTY |
Date: |
Mon, 31 Aug 2009 02:03:29 +0200 |
User-agent: |
KMail/1.9.9 |
Pádraig Brady wrote:
> I was wondering about this general issue a couple of days ago when pondering:
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=2bc0f3c
>
> At the application level we often want to check for this
> "not supported" condition while not caring where the failure occurred.
> I.E. I was wondering whether apps should usually be calling
> something like:
>
> bool not_supported (int error)
> {
> switch (error)
> {
> case ENOSYS: /* Function not implemented */
> case EOPNOTSUPP: /* Operation not supported */
> case ENOTSUP: /* Operation not supported */
> case ENOTTY: /* Inappropriate ioctl for device */
> return true;
> default:
> return false;
> }
> }
What do you want to do, if this function returns true? Sweep the
error under the rug? Well, in that case:
- For applications which are not security relevant, and where you want to
minimize the support effort, this might be ok.
- My policy is to ignore only errors that are known to indicate normal
situations. If a particular errno has not been seen in the wild so far,
don't ignore it. In general, and when in doubt, report errors.
- Jim's policy might even be stricter than mine.
I would not write a generic function like this. But one for ACLs is
acceptable (and exists: see ACL_NOT_WELL_SUPPORTED in lib/acl-internal.h).
Another one for fsync() is acceptable. Another one for specific socket
operations might be acceptable. Etc. The danger of a generic function of
this kind is that you keep adding errno values to it, until it contains
things like EOVERFLOW, ETIMEDOUT, EPERM, EACCES, ENAMETOOLONG, ... - and
at the end your entire application is hiding more and more errors and
behaving like a Windows app.
Bruno