Expose c_int as core::ffi::c_int?

[thomcc]

This is already part of the target specification, and you can observe the size of c_int in no_std programs by examining the size of a #[repr(C)] enum.

If we're worried about future platforms with a Rust compiler and no C compiler, on such a platform it would just be a signed integer the same size as a #[repr(C)] enum.

[sfackler]

The C standard does not mandate that enums be represented as an int:

Each enumerated type shall be compatible with char,asigned integer type, or an unsigned integer type. The choice of type is implementation-defined but shall be capable of representing the values of all the members of the enumeration.

[thomcc]

Right, on targets with actual C compilers it should match (and in practice Rust currently uses the c_int size specified in the target spec for repr(C) enums, AFAICT anyway).

That's just a way forward for deciding the behavior on some hypothetical target that has no C compiler, and thus no c_int

[clarfonthey]

There have been multiple requests to move the non-system-specific-but-still-target-specific stuff like c_int out of std and into core and alloc, and I definitely think there should be RFCs for them.

[joshtriplett]

I would love to see most of the basic FFI types moved into core::ffi.

[rvolosatovs]

Tracking issue rust-lang/rust#94501

[petrochenkov]

Closing in favor of the tracking issue.