| 1 | //! This module contains type aliases for C's fixed-width integer types . |
| 2 | //! |
|---|
| 3 | //! These aliases are deprecated: use the Rust types instead. |
|---|
| 4 | |
|---|
| 5 | #[deprecated (since = "0.2.55" , note = "Use i8 instead." )] |
|---|
| 6 | pub type int8_t = i8; |
|---|
| 7 | #[deprecated (since = "0.2.55" , note = "Use i16 instead." )] |
|---|
| 8 | pub type int16_t = i16; |
|---|
| 9 | #[deprecated (since = "0.2.55" , note = "Use i32 instead." )] |
|---|
| 10 | pub type int32_t = i32; |
|---|
| 11 | #[deprecated (since = "0.2.55" , note = "Use i64 instead." )] |
|---|
| 12 | pub type int64_t = i64; |
|---|
| 13 | #[deprecated (since = "0.2.55" , note = "Use u8 instead." )] |
|---|
| 14 | pub type uint8_t = u8; |
|---|
| 15 | #[deprecated (since = "0.2.55" , note = "Use u16 instead." )] |
|---|
| 16 | pub type uint16_t = u16; |
|---|
| 17 | #[deprecated (since = "0.2.55" , note = "Use u32 instead." )] |
|---|
| 18 | pub type uint32_t = u32; |
|---|
| 19 | #[deprecated (since = "0.2.55" , note = "Use u64 instead." )] |
|---|
| 20 | pub type uint64_t = u64; |
|---|
| 21 | |
|---|
| 22 | cfg_if! { |
|---|
| 23 | if #[cfg(all(target_arch = "aarch64" , not(target_os = "windows" )))] { |
|---|
| 24 | // This introduces partial support for FFI with __int128 and |
|---|
| 25 | // equivalent types on platforms where Rust's definition is validated |
|---|
| 26 | // to match the standard C ABI of that platform. |
|---|
| 27 | // |
|---|
| 28 | // Rust does not guarantee u128/i128 are sound for FFI, and its |
|---|
| 29 | // definitions are in fact known to be incompatible. [0] |
|---|
| 30 | // |
|---|
| 31 | // However these problems aren't fundamental, and are just platform |
|---|
| 32 | // inconsistencies. Specifically at the time of this writing: |
|---|
| 33 | // |
|---|
| 34 | // * For x64 SysV ABIs (everything but Windows), the types are underaligned. |
|---|
| 35 | // * For all Windows ABIs, Microsoft doesn't actually officially define __int128, |
|---|
| 36 | // and as a result different implementations don't actually agree on its ABI. |
|---|
| 37 | // |
|---|
| 38 | // But on the other major aarch64 platforms (android, linux, ios, macos) we have |
|---|
| 39 | // validated that rustc has the right ABI for these types. This is important because |
|---|
| 40 | // aarch64 uses these types in some fundamental OS types like user_fpsimd_struct, |
|---|
| 41 | // which represents saved simd registers. |
|---|
| 42 | // |
|---|
| 43 | // Any API which uses these types will need to `#[ignore(improper_ctypes)]` |
|---|
| 44 | // until the upstream rust issue is resolved, but this at least lets us make |
|---|
| 45 | // progress on platforms where this type is important. |
|---|
| 46 | // |
|---|
| 47 | // The list of supported architectures and OSes is intentionally very restricted, |
|---|
| 48 | // as careful work needs to be done to verify that a particular platform |
|---|
| 49 | // has a conformant ABI. |
|---|
| 50 | // |
|---|
| 51 | // [0]: https://github.com/rust-lang/rust/issues/54341 |
|---|
| 52 | |
|---|
| 53 | /// C `__int128` (a GCC extension that's part of many ABIs) |
|---|
| 54 | pub type __int128 = i128; |
|---|
| 55 | /// C `unsigned __int128` (a GCC extension that's part of many ABIs) |
|---|
| 56 | pub type __uint128 = u128; |
|---|
| 57 | /// C __int128_t (alternate name for [__int128][]) |
|---|
| 58 | pub type __int128_t = i128; |
|---|
| 59 | /// C __uint128_t (alternate name for [__uint128][]) |
|---|
| 60 | pub type __uint128_t = u128; |
|---|
| 61 | |
|---|
| 62 | // NOTE: if you add more platforms to here, you may need to cfg |
|---|
| 63 | // these consts. They should always match the platform's values |
|---|
| 64 | // for `sizeof(__int128)` and `_Alignof(__int128)`. |
|---|
| 65 | const _SIZE_128: usize = 16; |
|---|
| 66 | const _ALIGN_128: usize = 16; |
|---|
| 67 | |
|---|
| 68 | // FIXME(ctest): ctest doesn't handle `_` as an identifier so these tests are temporarily |
|---|
| 69 | // disabled. |
|---|
| 70 | // macro_rules! static_assert_eq { |
|---|
| 71 | // ($a:expr, $b:expr) => { |
|---|
| 72 | // const _: [(); $a] = [(); $b]; |
|---|
| 73 | // }; |
|---|
| 74 | // } |
|---|
| 75 | // |
|---|
| 76 | // // Since Rust doesn't officially guarantee that these types |
|---|
| 77 | // // have compatible ABIs, we const assert that these values have the |
|---|
| 78 | // // known size/align of the target platform's libc. If rustc ever |
|---|
| 79 | // // tries to regress things, it will cause a compilation error. |
|---|
| 80 | // // |
|---|
| 81 | // // This isn't a bullet-proof solution because e.g. it doesn't |
|---|
| 82 | // // catch the fact that llvm and gcc disagree on how x64 __int128 |
|---|
| 83 | // // is actually *passed* on the stack (clang underaligns it for |
|---|
| 84 | // // the same reason that rustc *never* properly aligns it). |
|---|
| 85 | // static_assert_eq!(core::mem::size_of::<__int128>(), _SIZE_128); |
|---|
| 86 | // static_assert_eq!(core::mem::align_of::<__int128>(), _ALIGN_128); |
|---|
| 87 | |
|---|
| 88 | // static_assert_eq!(core::mem::size_of::<__uint128>(), _SIZE_128); |
|---|
| 89 | // static_assert_eq!(core::mem::align_of::<__uint128>(), _ALIGN_128); |
|---|
| 90 | |
|---|
| 91 | // static_assert_eq!(core::mem::size_of::<__int128_t>(), _SIZE_128); |
|---|
| 92 | // static_assert_eq!(core::mem::align_of::<__int128_t>(), _ALIGN_128); |
|---|
| 93 | |
|---|
| 94 | // static_assert_eq!(core::mem::size_of::<__uint128_t>(), _SIZE_128); |
|---|
| 95 | // static_assert_eq!(core::mem::align_of::<__uint128_t>(), _ALIGN_128); |
|---|
| 96 | } |
|---|
| 97 | } |
|---|
| 98 | |
|---|
