|
| 1 | +//! Platform-specific types, as defined by C. |
| 2 | +//! |
| 3 | +//! Code that interacts via FFI will almost certainly be using the |
| 4 | +//! base types provided by C, which aren't nearly as nicely defined |
| 5 | +//! as Rust's primitive types. This module provides types which will |
| 6 | +//! match those defined by C, so that code that interacts with C will |
| 7 | +//! refer to the correct types. |
| 8 | +//! |
| 9 | +//! Contains only the primitive types, mod.rs contains additional types |
| 10 | +
|
| 11 | +type_alias! { "c_char.md", c_char = c_char_definition::c_char; #[doc(cfg(all()))] } |
| 12 | + |
| 13 | +type_alias! { "c_schar.md", c_schar = i8; } |
| 14 | +type_alias! { "c_uchar.md", c_uchar = u8; } |
| 15 | +type_alias! { "c_short.md", c_short = i16; } |
| 16 | +type_alias! { "c_ushort.md", c_ushort = u16; } |
| 17 | + |
| 18 | +type_alias! { "c_int.md", c_int = c_int_definition::c_int; #[doc(cfg(all()))] } |
| 19 | +type_alias! { "c_uint.md", c_uint = c_int_definition::c_uint; #[doc(cfg(all()))] } |
| 20 | + |
| 21 | +type_alias! { "c_long.md", c_long = c_long_definition::c_long; #[doc(cfg(all()))] } |
| 22 | +type_alias! { "c_ulong.md", c_ulong = c_long_definition::c_ulong; #[doc(cfg(all()))] } |
| 23 | + |
| 24 | +type_alias! { "c_longlong.md", c_longlong = i64; } |
| 25 | +type_alias! { "c_ulonglong.md", c_ulonglong = u64; } |
| 26 | + |
| 27 | +type_alias! { "c_float.md", c_float = f32; } |
| 28 | +type_alias! { "c_double.md", c_double = f64; } |
| 29 | + |
| 30 | +/// Equivalent to C's `size_t` type, from `stddef.h` (or `cstddef` for C++). |
| 31 | +/// |
| 32 | +/// This type is currently always [`usize`], however in the future there may be |
| 33 | +/// platforms where this is not the case. |
| 34 | +#[unstable(feature = "c_size_t", issue = "88345")] |
| 35 | +pub type c_size_t = usize; |
| 36 | + |
| 37 | +/// Equivalent to C's `ptrdiff_t` type, from `stddef.h` (or `cstddef` for C++). |
| 38 | +/// |
| 39 | +/// This type is currently always [`isize`], however in the future there may be |
| 40 | +/// platforms where this is not the case. |
| 41 | +#[unstable(feature = "c_size_t", issue = "88345")] |
| 42 | +pub type c_ptrdiff_t = isize; |
| 43 | + |
| 44 | +/// Equivalent to C's `ssize_t` (on POSIX) or `SSIZE_T` (on Windows) type. |
| 45 | +/// |
| 46 | +/// This type is currently always [`isize`], however in the future there may be |
| 47 | +/// platforms where this is not the case. |
| 48 | +#[unstable(feature = "c_size_t", issue = "88345")] |
| 49 | +pub type c_ssize_t = isize; |
| 50 | + |
| 51 | +mod c_char_definition { |
| 52 | + cfg_if! { |
| 53 | + // These are the targets on which c_char is unsigned. Usually the |
| 54 | + // signedness is the same for all target_os values on a given architecture |
| 55 | + // but there are some exceptions (see isSignedCharDefault() in clang). |
| 56 | + // |
| 57 | + // aarch64: |
| 58 | + // Section 10 "Arm C and C++ language mappings" in Procedure Call Standard for the Arm® |
| 59 | + // 64-bit Architecture (AArch64) says C/C++ char is unsigned byte. |
| 60 | + // https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings |
| 61 | + // arm: |
| 62 | + // Section 8 "Arm C and C++ Language Mappings" in Procedure Call Standard for the Arm® |
| 63 | + // Architecture says C/C++ char is unsigned byte. |
| 64 | + // https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs32/aapcs32.rst#arm-c-and-c-language-mappings |
| 65 | + // csky: |
| 66 | + // Section 2.1.2 "Primary Data Type" in C-SKY V2 CPU Applications Binary Interface |
| 67 | + // Standards Manual says ANSI C char is unsigned byte. |
| 68 | + // https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf |
| 69 | + // Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945). |
| 70 | + // hexagon: |
| 71 | + // Section 3.1 "Basic data type" in Qualcomm Hexagon™ Application |
| 72 | + // Binary Interface User Guide says "By default, the `char` data type is unsigned." |
| 73 | + // https://docs.qualcomm.com/bundle/publicresource/80-N2040-23_REV_K_Qualcomm_Hexagon_Application_Binary_Interface_User_Guide.pdf |
| 74 | + // msp430: |
| 75 | + // Section 2.1 "Basic Types" in MSP430 Embedded Application Binary |
| 76 | + // Interface says "The char type is unsigned by default". |
| 77 | + // https://www.ti.com/lit/an/slaa534a/slaa534a.pdf |
| 78 | + // powerpc/powerpc64: |
| 79 | + // - PPC32 SysV: "Table 3-1 Scalar Types" in System V Application Binary Interface PowerPC |
| 80 | + // Processor Supplement says ANSI C char is unsigned byte |
| 81 | + // https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf |
| 82 | + // - PPC64 ELFv1: Section 3.1.4 "Fundamental Types" in 64-bit PowerPC ELF Application |
| 83 | + // Binary Interface Supplement 1.9 says ANSI C is unsigned byte |
| 84 | + // https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUND-TYPE |
| 85 | + // - PPC64 ELFv2: Section 2.1.2.2 "Fundamental Types" in 64-Bit ELF V2 ABI Specification |
| 86 | + // says char is unsigned byte |
| 87 | + // https://openpowerfoundation.org/specifications/64bitelfabi/ |
| 88 | + // - AIX: XL C for AIX Language Reference says "By default, char behaves like an unsigned char." |
| 89 | + // https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=specifiers-character-types |
| 90 | + // riscv32/riscv64: |
| 91 | + // C/C++ type representations section in RISC-V Calling Conventions |
| 92 | + // page in RISC-V ELF psABI Document says "char is unsigned." |
| 93 | + // https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/draft-20240829-13bfa9f54634cb60d86b9b333e109f077805b4b3/riscv-cc.adoc#cc-type-representations |
| 94 | + // s390x: |
| 95 | + // - ELF: "Table 1.1.: Scalar types" in ELF Application Binary Interface s390x Supplement |
| 96 | + // Version 1.6.1 categorize ISO C char in unsigned integer |
| 97 | + // https://github.com/IBM/s390x-abi/releases/tag/v1.6.1 |
| 98 | + // - z/OS: XL C/C++ Language Reference says: "By default, char behaves like an unsigned char." |
| 99 | + // https://www.ibm.com/docs/en/zos/3.1.0?topic=specifiers-character-types |
| 100 | + // xtensa: |
| 101 | + // Section 2.17.1 "Data Types and Alignment" of Xtensa LX Microprocessor Overview handbook |
| 102 | + // says "`char` type is unsigned by default". |
| 103 | + // https://loboris.eu/ESP32/Xtensa_lx%20Overview%20handbook.pdf |
| 104 | + // |
| 105 | + // On the following operating systems, c_char is signed by default, regardless of architecture. |
| 106 | + // Darwin (macOS, iOS, etc.): |
| 107 | + // Apple targets' c_char is signed by default even on arm |
| 108 | + // https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Handle-data-types-and-data-alignment-properly |
| 109 | + // Windows: |
| 110 | + // Windows MSVC C++ Language Reference says "Microsoft-specific: Variables of type char |
| 111 | + // are promoted to int as if from type signed char by default, unless the /J compilation |
| 112 | + // option is used." |
| 113 | + // https://learn.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=msvc-170#character-types |
| 114 | + // L4Re: |
| 115 | + // The kernel builds with -funsigned-char on all targets (but useserspace follows the |
| 116 | + // architecture defaults). As we only have a target for userspace apps so there are no |
| 117 | + // special cases for L4Re below. |
| 118 | + // https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240 |
| 119 | + if #[cfg(all( |
| 120 | + not(windows), |
| 121 | + not(target_vendor = "apple"), |
| 122 | + any( |
| 123 | + target_arch = "aarch64", |
| 124 | + target_arch = "arm", |
| 125 | + target_arch = "csky", |
| 126 | + target_arch = "hexagon", |
| 127 | + target_arch = "msp430", |
| 128 | + target_arch = "powerpc", |
| 129 | + target_arch = "powerpc64", |
| 130 | + target_arch = "riscv32", |
| 131 | + target_arch = "riscv64", |
| 132 | + target_arch = "s390x", |
| 133 | + target_arch = "xtensa", |
| 134 | + ) |
| 135 | + ))] { |
| 136 | + pub(super) type c_char = u8; |
| 137 | + } else { |
| 138 | + // On every other target, c_char is signed. |
| 139 | + pub(super) type c_char = i8; |
| 140 | + } |
| 141 | + } |
| 142 | +} |
| 143 | + |
| 144 | +mod c_int_definition { |
| 145 | + cfg_if! { |
| 146 | + if #[cfg(any(target_arch = "avr", target_arch = "msp430"))] { |
| 147 | + pub(super) type c_int = i16; |
| 148 | + pub(super) type c_uint = u16; |
| 149 | + } else { |
| 150 | + pub(super) type c_int = i32; |
| 151 | + pub(super) type c_uint = u32; |
| 152 | + } |
| 153 | + } |
| 154 | +} |
| 155 | + |
| 156 | +mod c_long_definition { |
| 157 | + cfg_if! { |
| 158 | + if #[cfg(all(target_pointer_width = "64", not(windows)))] { |
| 159 | + pub(super) type c_long = i64; |
| 160 | + pub(super) type c_ulong = u64; |
| 161 | + } else { |
| 162 | + // The minimal size of `long` in the C standard is 32 bits |
| 163 | + pub(super) type c_long = i32; |
| 164 | + pub(super) type c_ulong = u32; |
| 165 | + } |
| 166 | + } |
| 167 | +} |
0 commit comments