Skip to content

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

Merged
merged 2 commits into from
Jun 25, 2016

Conversation

tbu-
Copy link
Contributor

@tbu- tbu- commented Jun 23, 2016

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.
@rust-highfive
Copy link
Contributor

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@tbu-
Copy link
Contributor Author

tbu- commented Jun 23, 2016

These syscalls can essentially only fail if an invalid file descriptor is passed to them.

@brson
Copy link
Contributor

brson commented Jun 23, 2016

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 assert! anyway - I'd sure like to know if somebody does hit an error here, and this isn't a fast path since we've just made a syscall.

@brson
Copy link
Contributor

brson commented Jun 23, 2016

cc @alexcrichton

@alexcrichton
Copy link
Member

If we actually check for errors here then seems like we should actually punt up the error, that's what we have Result for. These were added in a time where we didn't support construction from arbitrary file descriptors, so it didn't make sense to even check for an error here. It's pretty rare to even find C code that checks for errors against functions like this.

@retep998
Copy link
Member

It's pretty rare to even find C code that checks for errors against functions like this.

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 Result to be punted up, then it should probably apply to Windows as well.

@tbu-
Copy link
Contributor Author

tbu- commented Jun 24, 2016

Now the errors a bubbled up instead of being checked locally.

@alexcrichton
Copy link
Member

@bors: r+ 9347ffc

bors added a commit that referenced this pull request Jun 25, 2016
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.
@bors
Copy link
Collaborator

bors commented Jun 25, 2016

⌛ Testing commit 9347ffc with merge c128e9b...

@bors bors merged commit 9347ffc into rust-lang:master Jun 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants