Re: ignoring EOPNOTSUPP and ENOTTY

[Jim Meyering]

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

Mine is about the same.
Sometimes it's important to include a comment saying which system/version
produced a surprising errno value, so that we will be able to remove the
test when that version becomes unsupported.

I too have written generic functions like that in coreutils:

  copy.c:errno_unsupported (int err)
  remove.c:nonexistent_file_errno (int errnum)
  rmdir.c:errno_rmdir_non_empty (int error_number)
  rmdir.c:errno_may_be_empty (int error_number)
  shred.c:ignorable_sync_errno (int errno_val)

but I think they have to be highly application-specific.
Otherwise, the risk of a false positive would
seem to outweigh the benefit of factoring.