Re-export FFI definitions from core instead of re-defining them

[pheki]

Description

This PR removes definitions of FFI types that already exist in core and re-export them instead. The objective is to reduce duplication, to:

• Avoid making target maintainers having to change / add types in both places, potentially forgetting to update one of them.
• Avoid clashing definitions between std definitions and libc. For example, recently c_char changed from i8 to u8 for various targets, if you have a dependency that gets a *const libc::c_char and passes it to CStr::from_ptr, an older Cargo.lock will fail to compile in Rust 1.84.1 as e.g. CStr::from_ptr expects a *const i8 but libc 0.2.149 returns *const u8. This will not happen for future versions of libc if it re-exports these types from core.

Edit: after thinking more about it, do we even need to re-export these on 1.0? Can't we just remove them and let our users use core::ffi directly? (for 0.2 we still need them for backwards compatibility)

MSRV

Unfortunately, these definitions were only stabilized in core on Rust 1.84 1.64, so this would required a bump in the MSRV...

There's still no policy for MSRV, but the current value (1.83 1.63) was chosen as a conservative option due to being the one available in Debian Stable: #4040. The first freeze for the new Debian release (trixie) is scheduled to start on March and the Hard Freeze on May. Looking at the release history, it's probable that we will get the new version later this year.

So if this PR is to be approved, I'm guessing we could either merge it now or wait until Debian 13 "trixie" arrives.

Checklist

• Relevant tests in libc-test/semver have been updated: no API change
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI: This impacts all targets, I only tested it for my target.

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in solarish module

cc @jclulow, @pfmooney

Some changes occurred in OpenBSD module

cc @semarie

Some changes occurred in the Android module

cc @maurer

[tgross35]

Thank you for putting this together! I think that you are right that we should probably drop these entirely for 1.0, but don't do this now - that will probably have to be done not long before 1.0 is actually released (I am trying not to let the branches get too different so I can still feasibly diff between them).

Since this requires an MSRV change, we can't change 0.2 now as you pointed out. MSRV will be revisited after Trixie but I don't know what exactly the new minimum will be.

One concern is that we just did the big update to correct c_char; if anybody on pre-1.85 rustc has updated anything to correct for this, changing to reexport core would break them again.

@rustbot blocked

[tgross35]

I opened #4257 to track removing the reexports.

Based on the concerns above, I don't want to jump to reexporting core::ffi. I think we could still use the rest for cleanup though. Could you drop the changes to src/lib.rs and the MSRV bump? Instead, rename fixed_width_ints.rs to primitives.rs and copy the definitions from https://github.com/rust-lang/rust/blob/613bdd49978298648ed05ace086bd1ecad54b44a/library/core/src/ffi/mod.rs (without the type_alias macro).

This can then work for both branches.