Move universal libc types to the root by josephlr · Pull Request #1244 · rust-lang/libc (original) (raw)

@gnzlbg your concerns make sense. I'll refactor this to use a generic_ctypes cargo flag.

types like int64_t are optional in C, that is, they are not guaranteed to be defined for a target.

I would think about this a little differently, while there are some (extremely obscure) platforms that do not support C's int64_t, this crate necessarily only needs to think about Rust targets, and the Rust spec requires an i64 type. So if this crate can be compiled, int64_t exists and is equal to i64.

intptr_t and size_t don't necessarily need to have the same bit-width (e.g. on CHARI intptr_t is 128-bit wide but size_t is only 64-bit wide, etc.).

This is interesting (I couldn't find anything online about CHARI). I think it means that there are three fundamental categories of mandatory C types at play here.

  1. Types that have their value fixed by the union of the C and Rust standards
    - schar (i8), uchar (u8), int{8,116,32,64}_t (i{8,116,32,64}), uint{8,116,32,64}_t (u{8,116,32,64}), intptr_t (isize), uintptr_t (usize), float (f32), double (f64)
  2. Types that can technically have different values, but fixed in practice
    - int (i32), uint (u32), short (i16), ushort (u16), longlong, ptrdiff_t, ssize_t (isize), size_t, ulonglong, uintmax (usize)
  3. Types that actually vary from system to system (but have standard reasonable definitions)
    - char (u8 or i8), long(i32 or i64), ulong (u32 or u64), wchar (u32 or i32)

I'll change this PR to have (1) defined unambiguously in the libc root, and put (2) and (3) behind the generic_ctypes flag. Does that sound reasonable?

I would prefer to move all the ctype definitions into a separate crate, and for libc to depend on it. That would allow people that only want to use ctypes to not have to depend on libc. That crate could have a "generic" cargo feature that, for unsupported platforms, provides generic ctypes instead of providing nothing, and libc could re-export that feature (or not, just add a target-dependent dependency on ctypes instead of libc for custom targets).

This seems like the best ultimate solution. ring only uses C types (to allow for linking against BoringSSL's C code). How would this actually work, would ctypes still be part of this repo? I'm happy to help with getting this working, I just don't know how to do it.