-
Notifications
You must be signed in to change notification settings - Fork 19
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
Add type alias for raw OS errors #173
Comments
This is a perfect suggestion. Also, the current limitation of using i32 does not seem completely consistent inside std. The rust Finally, I have already merged rust-lang/rust#104001 which makes it easier to use custom entry points for custom targets and thus it would be great to have a more generic os errors. |
I agree with this change, it does seem like we want a more flexible definition of a raw OS error. @rustbot label +initial-comment-period |
Add type alias for raw OS errors Implement rust-lang/libs-team#173. `@rustbot` label +S-waiting-on-ACP +T-libs-api
Closing in favour of the tracking issue: rust-lang/rust#107792 |
Add type alias for raw OS errors Implement rust-lang/libs-team#173. `@rustbot` label +S-waiting-on-ACP +T-libs-api
Proposal
Problem statement
io::Error
assumes OS error values always fit into ani32
, but that is not true for all platforms.Motivation, use-cases
rust-lang/rust#105861 introduces
std
support for UEFI applications. There is however a problem with the way native OS errors are handled instd
, as the current API expects error values to fit into ani32
. While this the case for all currently supported platforms, UEFI diverges from the pattern by using anusize
1 as error type. This forces code supporting UEFI to convert the native errors to customio::Error
s, which does not fit well with the current API and looses information.Solution sketches
Add a new type alias to
std::io
(naming open to bikeshedding):and use it in place of
i32
inio::Error::from_raw_os_error
andio::Error::raw_os_error
. This is a backwards-compatible change on all current platforms, but new code wishing to support platforms like UEFI will need to use the new error type to ensure portability.CC @Ayush1325
Footnotes
At least according to the specification. However, error values always have the highest bit set, so
isize
would be more convenient... ↩The text was updated successfully, but these errors were encountered: