Skip to content

Commit 8614bd8

Browse files
ricci009ricci009
committed
refactoring, addition of c_long_definition and c_char_definition, primitive.rs tidy exception
1 parent a998838 commit 8614bd8

File tree

3 files changed

+116
-117
lines changed

3 files changed

+116
-117
lines changed

‎library/core/src/ffi/mod.rs

Lines changed: 6 additions & 109 deletions
Original file line numberDiff line numberDiff line change
@@ -49,117 +49,14 @@ macro_rules! type_alias {
4949
}
5050
}
5151

52-
#[stable(feature = "core_ffi", since = "1.30.0")]
52+
// Primitives contains listed types.
53+
// Contained in seperate file for simple parsing.
5354
mod primitives;
54-
5555
#[stable(feature = "core_ffi", since = "1.30.0")]
56-
pub use self::primitives::*;
57-
58-
mod c_char_definition {
59-
cfg_if! {
60-
// These are the targets on which c_char is unsigned. Usually the
61-
// signedness is the same for all target_os values on a given architecture
62-
// but there are some exceptions (see isSignedCharDefault() in clang).
63-
//
64-
// aarch64:
65-
// Section 10 "Arm C and C++ language mappings" in Procedure Call Standard for the Arm®
66-
// 64-bit Architecture (AArch64) says C/C++ char is unsigned byte.
67-
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings
68-
// arm:
69-
// Section 8 "Arm C and C++ Language Mappings" in Procedure Call Standard for the Arm®
70-
// Architecture says C/C++ char is unsigned byte.
71-
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs32/aapcs32.rst#arm-c-and-c-language-mappings
72-
// csky:
73-
// Section 2.1.2 "Primary Data Type" in C-SKY V2 CPU Applications Binary Interface
74-
// Standards Manual says ANSI C char is unsigned byte.
75-
// https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf
76-
// Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945).
77-
// hexagon:
78-
// Section 3.1 "Basic data type" in Qualcomm Hexagon™ Application
79-
// Binary Interface User Guide says "By default, the `char` data type is unsigned."
80-
// https://docs.qualcomm.com/bundle/publicresource/80-N2040-23_REV_K_Qualcomm_Hexagon_Application_Binary_Interface_User_Guide.pdf
81-
// msp430:
82-
// Section 2.1 "Basic Types" in MSP430 Embedded Application Binary
83-
// Interface says "The char type is unsigned by default".
84-
// https://www.ti.com/lit/an/slaa534a/slaa534a.pdf
85-
// powerpc/powerpc64:
86-
// - PPC32 SysV: "Table 3-1 Scalar Types" in System V Application Binary Interface PowerPC
87-
// Processor Supplement says ANSI C char is unsigned byte
88-
// https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf
89-
// - PPC64 ELFv1: Section 3.1.4 "Fundamental Types" in 64-bit PowerPC ELF Application
90-
// Binary Interface Supplement 1.9 says ANSI C is unsigned byte
91-
// https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUND-TYPE
92-
// - PPC64 ELFv2: Section 2.1.2.2 "Fundamental Types" in 64-Bit ELF V2 ABI Specification
93-
// says char is unsigned byte
94-
// https://openpowerfoundation.org/specifications/64bitelfabi/
95-
// - AIX: XL C for AIX Language Reference says "By default, char behaves like an unsigned char."
96-
// https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=specifiers-character-types
97-
// riscv32/riscv64:
98-
// C/C++ type representations section in RISC-V Calling Conventions
99-
// page in RISC-V ELF psABI Document says "char is unsigned."
100-
// https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/draft-20240829-13bfa9f54634cb60d86b9b333e109f077805b4b3/riscv-cc.adoc#cc-type-representations
101-
// s390x:
102-
// - ELF: "Table 1.1.: Scalar types" in ELF Application Binary Interface s390x Supplement
103-
// Version 1.6.1 categorize ISO C char in unsigned integer
104-
// https://github.com/IBM/s390x-abi/releases/tag/v1.6.1
105-
// - z/OS: XL C/C++ Language Reference says: "By default, char behaves like an unsigned char."
106-
// https://www.ibm.com/docs/en/zos/3.1.0?topic=specifiers-character-types
107-
// xtensa:
108-
// Section 2.17.1 "Data Types and Alignment" of Xtensa LX Microprocessor Overview handbook
109-
// says "`char` type is unsigned by default".
110-
// https://loboris.eu/ESP32/Xtensa_lx%20Overview%20handbook.pdf
111-
//
112-
// On the following operating systems, c_char is signed by default, regardless of architecture.
113-
// Darwin (macOS, iOS, etc.):
114-
// Apple targets' c_char is signed by default even on arm
115-
// https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Handle-data-types-and-data-alignment-properly
116-
// Windows:
117-
// Windows MSVC C++ Language Reference says "Microsoft-specific: Variables of type char
118-
// are promoted to int as if from type signed char by default, unless the /J compilation
119-
// option is used."
120-
// https://learn.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=msvc-170#character-types
121-
// L4Re:
122-
// The kernel builds with -funsigned-char on all targets (but useserspace follows the
123-
// architecture defaults). As we only have a target for userspace apps so there are no
124-
// special cases for L4Re below.
125-
// https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240
126-
if #[cfg(all(
127-
not(windows),
128-
not(target_vendor = "apple"),
129-
any(
130-
target_arch = "aarch64",
131-
target_arch = "arm",
132-
target_arch = "csky",
133-
target_arch = "hexagon",
134-
target_arch = "msp430",
135-
target_arch = "powerpc",
136-
target_arch = "powerpc64",
137-
target_arch = "riscv32",
138-
target_arch = "riscv64",
139-
target_arch = "s390x",
140-
target_arch = "xtensa",
141-
)
142-
))] {
143-
pub(super) type c_char = u8;
144-
} else {
145-
// On every other target, c_char is signed.
146-
pub(super) type c_char = i8;
147-
}
148-
}
149-
}
150-
151-
mod c_long_definition {
152-
cfg_if! {
153-
if #[cfg(all(target_pointer_width = "64", not(windows)))] {
154-
pub(super) type c_long = i64;
155-
pub(super) type c_ulong = u64;
156-
} else {
157-
// The minimal size of `long` in the C standard is 32 bits
158-
pub(super) type c_long = i32;
159-
pub(super) type c_ulong = u32;
160-
}
161-
}
162-
}
56+
pub use self::primitives::{
57+
c_char, c_double, c_float, c_int, c_long, c_longlong, c_ptrdiff_t, c_schar, c_short, c_size_t,
58+
c_ssize_t, c_uchar, c_uint, c_ulong, c_ulonglong, c_ushort,
59+
};
16360

16461
// N.B., for LLVM to recognize the void pointer type and by extension
16562
// functions like malloc(), we need to have it represented as i8* in

‎library/core/src/ffi/primitives.rs

Lines changed: 108 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,8 @@
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
1+
//! This module provides primitive types which will
62
//! match those defined by C, so that code that interacts with C will
73
//! refer to the correct types.
84
//!
9-
//! Contains only the primitive types, mod.rs contains additional types
10-
11-
#![stable(feature = "core_ffi", since = "1.30.0")]
5+
//! primitives.rs only contains type definitions for consistent external parsing
126
137
type_alias! { "c_char.md", c_char = c_char_definition::c_char; #[doc(cfg(all()))] }
148

@@ -29,6 +23,112 @@ type_alias! { "c_ulonglong.md", c_ulonglong = u64; }
2923
type_alias! { "c_float.md", c_float = f32; }
3024
type_alias! { "c_double.md", c_double = f64; }
3125

26+
mod c_char_definition {
27+
cfg_if! {
28+
// These are the targets on which c_char is unsigned. Usually the
29+
// signedness is the same for all target_os values on a given architecture
30+
// but there are some exceptions (see isSignedCharDefault() in clang).
31+
//
32+
// aarch64:
33+
// Section 10 "Arm C and C++ language mappings" in Procedure Call Standard for the Arm®
34+
// 64-bit Architecture (AArch64) says C/C++ char is unsigned byte.
35+
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings
36+
// arm:
37+
// Section 8 "Arm C and C++ Language Mappings" in Procedure Call Standard for the Arm®
38+
// Architecture says C/C++ char is unsigned byte.
39+
// https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs32/aapcs32.rst#arm-c-and-c-language-mappings
40+
// csky:
41+
// Section 2.1.2 "Primary Data Type" in C-SKY V2 CPU Applications Binary Interface
42+
// Standards Manual says ANSI C char is unsigned byte.
43+
// https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf
44+
// Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945).
45+
// hexagon:
46+
// Section 3.1 "Basic data type" in Qualcomm Hexagon™ Application
47+
// Binary Interface User Guide says "By default, the `char` data type is unsigned."
48+
// https://docs.qualcomm.com/bundle/publicresource/80-N2040-23_REV_K_Qualcomm_Hexagon_Application_Binary_Interface_User_Guide.pdf
49+
// msp430:
50+
// Section 2.1 "Basic Types" in MSP430 Embedded Application Binary
51+
// Interface says "The char type is unsigned by default".
52+
// https://www.ti.com/lit/an/slaa534a/slaa534a.pdf
53+
// powerpc/powerpc64:
54+
// - PPC32 SysV: "Table 3-1 Scalar Types" in System V Application Binary Interface PowerPC
55+
// Processor Supplement says ANSI C char is unsigned byte
56+
// https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf
57+
// - PPC64 ELFv1: Section 3.1.4 "Fundamental Types" in 64-bit PowerPC ELF Application
58+
// Binary Interface Supplement 1.9 says ANSI C is unsigned byte
59+
// https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUND-TYPE
60+
// - PPC64 ELFv2: Section 2.1.2.2 "Fundamental Types" in 64-Bit ELF V2 ABI Specification
61+
// says char is unsigned byte
62+
// https://openpowerfoundation.org/specifications/64bitelfabi/
63+
// - AIX: XL C for AIX Language Reference says "By default, char behaves like an unsigned char."
64+
// https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=specifiers-character-types
65+
// riscv32/riscv64:
66+
// C/C++ type representations section in RISC-V Calling Conventions
67+
// page in RISC-V ELF psABI Document says "char is unsigned."
68+
// https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/draft-20240829-13bfa9f54634cb60d86b9b333e109f077805b4b3/riscv-cc.adoc#cc-type-representations
69+
// s390x:
70+
// - ELF: "Table 1.1.: Scalar types" in ELF Application Binary Interface s390x Supplement
71+
// Version 1.6.1 categorize ISO C char in unsigned integer
72+
// https://github.com/IBM/s390x-abi/releases/tag/v1.6.1
73+
// - z/OS: XL C/C++ Language Reference says: "By default, char behaves like an unsigned char."
74+
// https://www.ibm.com/docs/en/zos/3.1.0?topic=specifiers-character-types
75+
// xtensa:
76+
// Section 2.17.1 "Data Types and Alignment" of Xtensa LX Microprocessor Overview handbook
77+
// says "`char` type is unsigned by default".
78+
// https://loboris.eu/ESP32/Xtensa_lx%20Overview%20handbook.pdf
79+
//
80+
// On the following operating systems, c_char is signed by default, regardless of architecture.
81+
// Darwin (macOS, iOS, etc.):
82+
// Apple targets' c_char is signed by default even on arm
83+
// https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Handle-data-types-and-data-alignment-properly
84+
// Windows:
85+
// Windows MSVC C++ Language Reference says "Microsoft-specific: Variables of type char
86+
// are promoted to int as if from type signed char by default, unless the /J compilation
87+
// option is used."
88+
// https://learn.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=msvc-170#character-types
89+
// L4Re:
90+
// The kernel builds with -funsigned-char on all targets (but useserspace follows the
91+
// architecture defaults). As we only have a target for userspace apps so there are no
92+
// special cases for L4Re below.
93+
// https://github.com/rust-lang/rust/pull/132975#issuecomment-2484645240
94+
if #[cfg(all(
95+
not(windows),
96+
not(target_vendor = "apple"),
97+
any(
98+
target_arch = "aarch64",
99+
target_arch = "arm",
100+
target_arch = "csky",
101+
target_arch = "hexagon",
102+
target_arch = "msp430",
103+
target_arch = "powerpc",
104+
target_arch = "powerpc64",
105+
target_arch = "riscv32",
106+
target_arch = "riscv64",
107+
target_arch = "s390x",
108+
target_arch = "xtensa",
109+
)
110+
))] {
111+
pub(super) type c_char = u8;
112+
} else {
113+
// On every other target, c_char is signed.
114+
pub(super) type c_char = i8;
115+
}
116+
}
117+
}
118+
119+
mod c_long_definition {
120+
cfg_if! {
121+
if #[cfg(all(target_pointer_width = "64", not(windows)))] {
122+
pub(super) type c_long = i64;
123+
pub(super) type c_ulong = u64;
124+
} else {
125+
// The minimal size of `long` in the C standard is 32 bits
126+
pub(super) type c_long = i32;
127+
pub(super) type c_ulong = u32;
128+
}
129+
}
130+
}
131+
32132
/// Equivalent to C's `size_t` type, from `stddef.h` (or `cstddef` for C++).
33133
///
34134
/// This type is currently always [`usize`], however in the future there may be

‎src/tools/tidy/src/pal.rs

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -50,6 +50,8 @@ const EXCEPTION_PATHS: &[&str] = &[
5050
"library/core/src/ffi/va_list.rs",
5151
// We placed a linkage against Windows libraries here
5252
"library/core/src/ffi/mod.rs",
53+
// Linkage against Windows libraries here
54+
"library/core/src/ffi/primitives.rs",
5355
"library/std/src/sys", // Platform-specific code for std lives here.
5456
"library/std/src/os", // Platform-specific public interfaces
5557
// Temporary `std` exceptions

0 commit comments

Comments
 (0)