std: map ENOTSUP to ErrorKind::Unsupported

[valentynkit]

ENOTSUP and EOPNOTSUPP both mean the operation isn't supported. They're the same value on some targets (Linux, FreeBSD), where the existing EOPNOTSUPP => Unsupported arm (#139822) already covers both, and different on others (Apple, OpenBSD), where ENOTSUP decodes to Uncategorized instead. I don't see a reason to treat it differently, so this maps ENOTSUP to Unsupported as well.

It uses a match guard rather than an or-pattern, since the two are equal on the targets where they alias and an or-pattern would be unreachable there. Same shape as the EAGAIN/EWOULDBLOCK arm just below:

x if x == libc::EOPNOTSUPP || x == libc::ENOTSUP => Unsupported,

This was raised once before (#125228) and closed, since both errnos were left out of the original Unsupported PR (#78880). #139822 has since added EOPNOTSUPP, so the same reasoning now covers ENOTSUP.

I didn't add a test, since the decode arms aren't tested today.

r? libs

[workingjubilee]

No reasoning was given in the PR where the behavior was changed. It was simply claimed to be incorrect.

[workingjubilee]

As far as I understand it, ErrorKind::Unsupported is intended to map to "never succeeds", which is not what this error code indicates. Making the behavior more incorrect because a previous PR made it incorrect, by itself simply claiming it was incorrect, does not seem desirable to me. I'm not sure what else we should be doing though.

[ds84182]

https://lists.gnu.org/archive/html/bug-glibc/2002-08/msg00017.html

POSIX 1003.1-200 defines the errors EOPNOTSUPP and ENOTSUP as follows:

[ENOTSUP] Not supported. The implementation does not support this feature of the Realtime Option Group.

[EOPNOTSUPP] Operation not supported on socket. The type of socket (address family or protocol) does not support the requested operation.

So EOPNOTSUPP is specifically for sockets and ENOTSUP is for everything else. The generally accepted error message seems to be "Operation is not supported on transport endpoint" for EOPNOTSUPP.

[valentynkit]

No reasoning was given in the PR where the behavior was changed. It was simply claimed to be incorrect.

You're right that I didn't justify in PR the mapping beyond calling the old one incorrect, so I won't lean on it as precedent.

[ENOTSUP]
Not supported (may be the same value as [EOPNOTSUPP]).
The split only shows up on Apple and the BSDs, and only because ENOTSUP got left out. So this isn't adding a new behavior, it's making one errno categorize the same way across targets instead of dropping to Uncategorized on Apple alone.

The reason I'd keep the two together is simpler: ENOTSUP and EOPNOTSUPP are the same integer on Linux, Android and FreeBSD, so an ENOTSUP error already decodes to Unsupported there through the existing arm.

So EOPNOTSUPP is specifically for sockets and ENOTSUP is for everything else. The generally accepted error message seems to be "Operation is not supported on transport endpoint" for EOPNOTSUPP.

You're right that neither strictly means "never succeeds on this platform" (both can be per-socket or per-fs), so I'm happy to take the broader question to a separate issue if you'd rather reconsider Unsupported for both, reverting #139822 included.

The goal is portability: an ENOTSUP fallback that matches ErrorKind::Unsupported shouldn't work on Linux but silently miss on macOS. Left as-is, ENOTSUP just stays inconsistent with EOPNOTSUPP on the targets where they differ.

[workingjubilee]

You're right that I didn't justify in PR the mapping beyond calling the old one incorrect, so I won't lean on it as precedent.

...Typo? That was by @ozgureyilmaz, so surely it was not your responsibility to justify the PR that you did not author.

But yes, I think we can agree that whatever is decided, the reasoning should be able to stand on its own. And I can see the argument for making the change. At the very least, surely we should be offering something better than just "Uncategorized".