search

rust-lang / miri

An interpreter for Rust's mid-level intermediate representation
Apache License 2.0
4.16k stars 318 forks source link

strerror based on ErrorKind is technically valid but surprising #3612

Open saethlin opened 1 month ago

saethlin commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.