Re: ignoring EOPNOTSUPP and ENOTTY

[Bruno Haible]

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