Tracking Issue for core_ffi_c

[joshtriplett]

Feature gate: #![feature(core_ffi_c)]

This is a tracking issue for providing the aliases for C types (c_int, c_char, etc) via core::ffi, not just via std::os::raw. The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std.

Public API

// core::ffi

pub type c_char = ...;
pub type c_short = ...;
pub type c_ushort = ...;
pub type c_int = ...;
pub type c_uint = ...;
// ...

The existing types in std::os::raw will become type aliases for the ones in core::ffi. This will use type aliases rather than re-exports, to allow the std types to remain stable while the core types are unstable.

This also moves the currently unstable NonZero variants and c_size_t/c_ssize_t/c_ptrdiff_t types to core::ffi, while leaving them unstable.

Steps / History

• Implementation: Provide C FFI types via core::ffi, not just in std #94503
• Final comment period (FCP)
• Stabilization PR

[bstrie]

To clarify, was #94503 able to avoid insta-stability of the new items? There seems to be some confusion as to whether or not type aliases respect stability markers.

[joshtriplett]

@bstrie It appears so: core::ffi::c_ulong shows up as unstable, while std::os::raw::c_ulong shows up as stable.

[madsmtm]

The introductory docs for core currently says:

this library is platform-agnostic

So that should probably be modified slightly if we go with this change? (Which I am greatly in favour of btw)