strerror based on ErrorKind is technically valid but surprising

[saethlin]

POSIX says precious little about what strerror does other than it produces a string. https://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html

The current implementation we have for strerror is based on converting the error code to a std::io::ErrorKind:
https://github.com/rust-lang/miri/blob/e1099c653869d18d2590bc3366b74b96a70997b1/src/shims/unix/foreign_items.rs#L571C34-L576

This conversion is lossy. In particular, both ENOTSUP and ENOSYS map to ErrorKind::Unsupported, even though every libc will produce different error messages for those. It would be nice if we could mirror the behavior of a good libc. Error reporting is not the right place to follow only the letter of the law.

[RalfJung]

The current implementation mostly exists so we don't have to maintain a table of strings (for error descriptions) ourselves, but can reuse someone else's code...

[RalfJung]

In particular, both ENOTSUP and ENOSYS map to ErrorKind::Unsupported

I can't find ENOTSUP mapping to anything? Where is it mapped to ErrorKind::Unsupported?

[saethlin]

Ah! Yes. The library simply does not have such a mapping at all, which means that our shim doesn't know how to construct strings for errors not exposed by the standard library.

Where is it mapped to ErrorKind::Unsupported?

I was misremembering an FCP discussion.