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)

[SimonSapin]

Should these items also be available in std::ffi, in order to keep std a superset of core? (Though in this case it’s redundant with std::os::raw)

[joshtriplett]

@SimonSapin They were, but that was reverted in 07ea143 because it caused breakage; we can re-add it as re-exports when we stabilize this.

[joshtriplett]

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)

core is platform-agnostic: it's skeptical about platforms but doesn't deny their existence

More seriously: I think the key detail here is that core doesn't offer any interfaces to platform functionality; it doesn't call into the platform. I think offering portable types whose layout is platform-specific doesn't invalidate that. core also has interfaces which use usize, whose size varies by platform.

[joshtriplett]

Following up from Zulip:

@rust-lang/libs-api, shall we stabilize the core::ffi::c_* types?

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[BurntSushi]

To be clear, this also includes adding these types to std::ffi too?

[joshtriplett]

@BurntSushi Yes.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[joshtriplett]

Stabilized in #98315