Tracking Issue for `RawOsError`

[joboet]

Feature gate: #![feature(raw_os_error_ty)]

This is a tracking issue for the raw OS error type alias, used in io::Error::raw_os_error and io::Error::from_raw_os_error (both are stable APIs).

std used to assume that the OS error type (return by errno and such) is an i32. This is however not the case on platforms like UEFI (which uses usize). To ensure idiomatic and convenient handling of native errors without loosing information, the RawOsError type is introduced to allow future ports of the standard library to use the correct error type for their respective platform. As this does not change the error type on already supported targets, this is a backwards-compatible change. Current software can still use i32 directly while the RawOsError type alias is unstable. However, this feature should probably be stabilized before ports using a different type are merged, to allow software to be more easily ported.

Public API

// std::io

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

Steps / History

• API change proposal: Add type alias for raw OS errors libs-team#173
• Implementation: Add type alias for raw OS errors #107519
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[GuillaumeGomez]

Just commenting on this to say that the Error::raw_os_error is stable whereas the type alias (returned by this function) isn't, which doesn't make much sense.

[PrasannaPaithankar]

Just commenting on this to say that the Error::raw_os_error is stable whereas the type alias (returned by this function) isn't, which doesn't make much sense.

Any updates on this @joboet ?

[lasiotus]

The current implementation assumes that RawOsError is a integer of 32 bits or less. It would be nice if enums of #[repr(u32)] or similar were accepted: I tried to use a #[repr(u16)] enum, but the compiler said "No"...

[lasiotus]

The current implementation assumes that RawOsError is a integer of 32 bits or less.

And anything other than i32 is not actually practical for a target that wants wider ecosystem support, as some essential downstream crates assume that errno is i32.

[CodesInChaos]

It would be nice if enums of #[repr(u32)] or similar were accepted

Enums are problematic, because they can only represent known variants. So if the OS adds a new variant, interpreting it as a RawOsError would be undefined behavior.

But what I'd like to see is support for transparent newtype wrappers around an integer type. This would have most of type safety benefits of an enum, while being open to extension. It would also allow cases like 64-bit integers where a couple of bits must have a fixed value (to enable bit-packing).

And anything other than i32 is not actually practical for a target that wants wider ecosystem support, as some essential downstream crates assume that errno is i32.

At least the lines you show can trivially be replaced by RawOsError once it's stabilized. The question is if the i32 assumption is baked in more deeply in a popular crate.

[lygstate]

How about move RawOsError into core::ffi as core:ffi::c_errno_t

[bjoernager]

How about move RawOsError into core::ffi as core:ffi::c_errno_t

errno must have the int type, thus c_errno_t would be equivalent to c_int. RawOsError, meanwhile, is (currently) either i32 (equivalent to C's int32_t) or usize (equivalent to C's uintptr_t,) with the former only sometimes being compatible with c_int and the latter never being compatible with c_int.

[lygstate]

How about move RawOsError into core::ffi as core:ffi::c_errno_t

errno must have the int type, thus c_errno_t would be equivalent to c_int. RawOsError, meanwhile, is (currently) either i32 (equivalent to C's int32_t) or usize (equivalent to C's uintptr_t,) with the former only sometimes being compatible with c_int and the latter never being compatible with c_int.

Oh, sorry for the typo, I means core::ffi:os_errno_t