Re: ignoring EOPNOTSUPP and ENOTTY

[Pádraig Brady]

Bruno Haible wrote:
> 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.

The application could use this for operations it deems optional for example.

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

OK.
The downside is that one has to add the errors to each call,
piecemeal as they're noticed on various system combinations.
I thought there might be a benefit from rolling up some errors
that would never be treated separately by many apps.

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

OK.

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

Well I wouldn't add more to it, I'd call it from
for specific whatever_unsupported() functions.
But I agree that if one is always going to be using
specific unsupported() functions, then having a generic
one is not of much use.

Thanks for the feedback guys.

Pádraig.