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
