-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove use of locale-specific strerror_r
.
#440
Conversation
// Take up to trailing null byte | ||
let n = buf.len(); | ||
let idx = buf.iter().position(|&b| b == 0).unwrap_or(n); | ||
core::str::from_utf8(&buf[..idx]).ok() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the bytes do not contain any invalid UTF-8 sequences, they might not be encoding UTF-8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there an actual example of this being an issue on a unix
target?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No offense, but I don't participate in that kind of thinking. Instead it would be better to have a proof that it isn't an issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no offense taken, I think this is a good point (especially when it comes to stuff like the safety of code or cryptographic security where I 100% agree). Sorry for being a little short. I just meant to note that an implementation returning UTF8 bytes that aren't UTF8 only causes the display implementation to show a suboptimal error string.
However, after looking more into strerror_r
, I agree that we shouldn't be assuming that it is well behaved on arbitrary unix
targets. This is libstd
's job, not ours. See my suggestion below.
Edit: I think we can actually remove use of |
After looking at this some more (and reading more about impl fmt::Display for Error {
fn fmt(&self, f: &mut Formatter) {
if let Some(errno) = self.raw_os_error() {
#[cfg(feature = "std")]
std::io::Error::from_raw_os_error(error).fmt(f)
#[cfg(not(feature = "std"))]
write!(f, "OS error {}", errno)
} else {
...
}
}
} |
I agree with the @josephlr's suggestion above. |
This would mean that the output would depend on the |
Arguably, the main reason for the |
strerror_r doesn't necessarily return UTF-8 but we assume it does. strerror_r is locale-sensitive but we are better off not being locale-sensitive. strerror_r requires us to use libc but increasingly we want to avoid libc, e.g. to support x86_64-unknown-linux-none. Just remove the use of the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix!!
strerror_r doesn't necessarily return UTF-8 but we assume it does.
strerror_r is locale-sensitive but we are better off not being locale-sensitive.
strerror_r requires us to use libc but increasingly we want to avoid libc, e.g. to support x86_64-unknown-linux-none.
Just remove the use of the function.