-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
dd: use seek for stdin skip when possible #9821
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
base: main
Are you sure you want to change the base?
Conversation
|
GNU testsuite comparison: |
| } | ||
| Ok(pos) | ||
| } | ||
| Some(Err(e)) if e.raw_os_error() == Some(libc::ESPIPE) => { |
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.
I usually prefer using e.kind() over e.raw_os_error(). Is there a reason to use libc::ESPIPE over ?std::io::NotSeekable
Edit: Realized that std::io::NotSeekable might not be the equivalent code for this on documentation
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.
Wait, is lib::ESPIPE not equivalently supported through Rust's ErrorKind?
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.
I'm unsure what the difference is between the two, I can try it out now to see if it still passes all of the tests
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.
There isn't a difference between using libc's errors or Rust's ErrorKind; I just thought it looks a bit more idiomatic relying on Rust's ErrorKind over libc's errno values.
But I think this is one of those cases where libc::ESPIPE might fall under Rust's std::io::Other error, which isn't that descriptive.
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.
Yea this one is not the equivalent, the stable ErrorKind does not have a matching variant for this use case.
The dd/skip-seek-past-file test is checking that the default implementation uses skip as the reader by putting a set of inputs that would cause an out of bounds read if skip was not used, but for things like pipe inputs using copy is the right approach to use and we have other GNU tests that rely on that behaviour. This PR uses skip as the default then falls back to copy.