Skip to content
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

Closed
joboet opened this issue Jan 31, 2023 · 3 comments
Closed

Add type alias for raw OS errors #173

joboet opened this issue Jan 31, 2023 · 3 comments
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api

Comments

@joboet
Copy link
Member

joboet commented Jan 31, 2023

Proposal

Problem statement

io::Error assumes OS error values always fit into an i32, 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 in std, as the current API expects error values to fit into an i32. While this the case for all currently supported platforms, UEFI diverges from the pattern by using an usize1 as error type. This forces code supporting UEFI to convert the native errors to custom io::Errors, 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):

pub type RawOsError = /* platform error type, `i32` most of the time */;

and use it in place of i32 in io::Error::from_raw_os_error and io::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

  1. At least according to the specification. However, error values always have the highest bit set, so isize would be more convenient...

@joboet joboet added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Jan 31, 2023
@Ayush1325
Copy link

This is a perfect suggestion.

Also, the current limitation of using i32 does not seem completely consistent inside std. The rust lang_start returns isize and not i32.

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.

@Amanieu
Copy link
Member

Amanieu commented Feb 3, 2023

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

@rustbot rustbot added the initial-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Feb 3, 2023
compiler-errors added a commit to compiler-errors/rust that referenced this issue Feb 3, 2023
Add type alias for raw OS errors

Implement rust-lang/libs-team#173.

`@rustbot` label +S-waiting-on-ACP +T-libs-api
@joboet
Copy link
Member Author

joboet commented Mar 12, 2023

Closing in favour of the tracking issue: rust-lang/rust#107792

@joboet joboet closed this as completed Mar 12, 2023
thomcc pushed a commit to tcdi/postgrestd that referenced this issue May 31, 2023
thomcc pushed a commit to tcdi/postgrestd that referenced this issue May 31, 2023
Add type alias for raw OS errors

Implement rust-lang/libs-team#173.

`@rustbot` label +S-waiting-on-ACP +T-libs-api
@dtolnay dtolnay added ACP-accepted API Change Proposal is accepted (seconded with no objections) and removed initial-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Nov 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api
Projects
None yet
Development

No branches or pull requests

5 participants