-
Notifications
You must be signed in to change notification settings - Fork 20
Add type alias for raw OS errors #173
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: