-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Don't ignore errors of syscalls in std::sys::unix::fd #34441
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
Conversation
If any of these syscalls fail, it indicates a programmer error that should not be silently ignored.
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
These syscalls can essentially only fail if an invalid file descriptor is passed to them. |
It's not obvious to me that it's possible for these to return errors. Do you have scenarios in mind where these won't return 0? Edit: I see you mentioned they only fail when passed invalid descriptors. (I'm not clear on how exposed to user code these are. Are these just internal implementation details or can people use them to call cloexec on arbitrary file descriptors?) Even if it's not supposed to be possible for these to return errors it may be prudent to convert these to |
If we actually check for errors here then seems like we should actually punt up the error, that's what we have |
I don't think we should base Rust's error handling on the dangerous footgun that is C. There are a few cases where system function errors are being ignored on Windows too. If any way is thought up to allow |
Now the errors a bubbled up instead of being checked locally. |
Don't ignore errors of syscalls in std::sys::unix::fd If any of these syscalls fail, it indicates a programmer error that should not be silently ignored.
If any of these syscalls fail, it indicates a programmer error that
should not be silently ignored.