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.
