On Nov 11 2016, Mike Marshall <hubcap@xxxxxxxxxxxx> wrote:
> There was a memorable place in the Orangefs code where
> the original programmer did that (pick something appropriate
> from errno.h) and put in a comment about how it was a more
> reasonable return code...
>
> When Al Viro saw it, he said it was:
>
> ... stupid. Expected error value is not EOPNOTSUPP; pardon the bluntness,
> but your idea of what would be less misleading doesn't matter - what matters
> is what the _callers_ of link(2), mknod(2), etc. are expecting. Which is to
> say, what does the userland code expect to get. It's outright promised in
> POSIX, actually.
I still have to see an application that, upon receiving an error from
e.g. link(2), has special handlers for each of the 24 possible 24 error
codes. All code that I have seen (and written) check for a few specific
errors, and punts everything else to the user via strerror(). In this
case, returning more specific error codes gives the user better
information and doesn't violate any expectations of the application.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
