Add ENOTSUP to Linux and Android

[jmmv]

While ENOTSUP is defined as equal to EOPNOTSUPP on these platforms,
exposing the ENOTSUP symbol (as libc does) allows for writing portable
code that may want to reference this error code.

[jmmv]

I have no idea if this will work. Created the PR to trigger a CI build and seeing what happens.

[asomers]

I'm not sure about this PR. What portability advantages does ENOTSUP have ove EOPNOTSUP?

[jmmv]

I had some code that returned Errno::ENOTSUP. This built and worked fine on macOS, but when I tried the same code on Linux, it failed because Linux didn't expose this symbol. Therefore, it is not possible to have such code today while keeping it portable.

(I changed my code to EOPNOTSUPP instead because I don't really care about the value, and this works on both macOS and Linux. But the issue remains and I guess it could confuse someone else in the future or prevent some form of code that truly needs to use ENOTSUP.)

[jmmv]

Just getting back to this because of bazelbuild/sandboxfs#72. Note how my "fix" to use EOPNOTSUPP to support Linux and macOS was not good: this symbols doesn't exist in FreeBSD and the reporter suggested switching to ENOTSUP instead because it would work on other systems (but it wouldn't). I think we should expose both symbols all the time.

[asomers]

Ok, but let's not duplicate libc's job. Instead of defining ENOTSUP as an alias for EOPNOTSUP we should just expose whatever libc exposes. As you wrote it, the build will fail on NetBSD because libc doesn't expose EOPNOTSUP on that platform. Things are even worse on OSX and Newlib, where EOPNOTSUP is distinct from ENOTSUP.

[jmmv]

OK, so I'm not sure how you'd like to achieve this.

First, the changes I made are all within a chunk of code that is gated by a #cfg for Linux and Android only, so I cannot see how they could break NetBSD nor macOS per your last comment.

Second, I tried adding ENOTSUP = libc::ENOTSUP within the Errno enum for Linux, but that doesn't work because we end up with two different Errno entries that map to the same numeric value.

And lastly, note that the line I'm adding exists next to definitions for EWOULDBLOCK and EDEADLOCK outside of the enum that explicitly map to other values (thus theoretically duplicating logic within libc). I'm guessing they do this precisely for the same reason I'm trying to expose ENOTSUP. So copying whatever is there already seems sensible.

[asomers]

I didn't realize that Rust enforced a uniqueness constraint for enums. Ok, let's commit this then.

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push
• FreeBSD 11.2