@@ -90,6 +90,7 @@ pub type c_ptrdiff_t = isize;
90
90
pub type c_ssize_t = isize ;
91
91
92
92
mod c_char_definition {
93
+ #[ cfg( bootstrap) ]
93
94
cfg_if ! {
94
95
// These are the targets on which c_char is unsigned. Usually the
95
96
// signedness is the same for all target_os values on a given architecture
@@ -180,9 +181,101 @@ mod c_char_definition {
180
181
pub ( super ) type c_char = i8 ;
181
182
}
182
183
}
184
+ #[ cfg( not( bootstrap) ) ]
185
+ crate :: cfg_match! {
186
+ // These are the targets on which c_char is unsigned. Usually the
187
+ // signedness is the same for all target_os values on a given architecture
188
+ // but there are some exceptions (see isSignedCharDefault() in clang).
189
+ //
190
+ // aarch64:
191
+ // Section 10 "Arm C and C++ language mappings" in Procedure Call Standard for the Arm®
192
+ // 64-bit Architecture (AArch64) says C/C++ char is unsigned byte.
193
+ // https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings
194
+ // arm:
195
+ // Section 8 "Arm C and C++ Language Mappings" in Procedure Call Standard for the Arm®
196
+ // Architecture says C/C++ char is unsigned byte.
197
+ // https://github.com/ARM-software/abi-aa/blob/2024Q3/aapcs32/aapcs32.rst#arm-c-and-c-language-mappings
198
+ // csky:
199
+ // Section 2.1.2 "Primary Data Type" in C-SKY V2 CPU Applications Binary Interface
200
+ // Standards Manual says ANSI C char is unsigned byte.
201
+ // https://github.com/c-sky/csky-doc/blob/9f7121f7d40970ba5cc0f15716da033db2bb9d07/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf
202
+ // Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945).
203
+ // hexagon:
204
+ // Section 3.1 "Basic data type" in Qualcomm Hexagon™ Application
205
+ // Binary Interface User Guide says "By default, the `char` data type is unsigned."
206
+ // https://docs.qualcomm.com/bundle/publicresource/80-N2040-23_REV_K_Qualcomm_Hexagon_Application_Binary_Interface_User_Guide.pdf
207
+ // msp430:
208
+ // Section 2.1 "Basic Types" in MSP430 Embedded Application Binary
209
+ // Interface says "The char type is unsigned by default".
210
+ // https://www.ti.com/lit/an/slaa534a/slaa534a.pdf
211
+ // Note: this doesn't seem to match Clang's default (https://github.com/rust-lang/rust/issues/129945).
212
+ // powerpc/powerpc64:
213
+ // - PPC32 SysV: "Table 3-1 Scalar Types" in System V Application Binary Interface PowerPC
214
+ // Processor Supplement says ANSI C char is unsigned byte
215
+ // https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf
216
+ // - PPC64 ELFv1: Section 3.1.4 "Fundamental Types" in 64-bit PowerPC ELF Application
217
+ // Binary Interface Supplement 1.9 says ANSI C is unsigned byte
218
+ // https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUND-TYPE
219
+ // - PPC64 ELFv2: Section 2.1.2.2 "Fundamental Types" in 64-Bit ELF V2 ABI Specification
220
+ // says char is unsigned byte
221
+ // https://openpowerfoundation.org/specifications/64bitelfabi/
222
+ // - AIX: XL C for AIX Language Reference says "By default, char behaves like an unsigned char."
223
+ // https://www.ibm.com/docs/en/xl-c-aix/13.1.3?topic=specifiers-character-types
224
+ // riscv32/riscv64:
225
+ // C/C++ type representations section in RISC-V Calling Conventions
226
+ // page in RISC-V ELF psABI Document says "char is unsigned."
227
+ // https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/draft-20240829-13bfa9f54634cb60d86b9b333e109f077805b4b3/riscv-cc.adoc#cc-type-representations
228
+ // s390x:
229
+ // - ELF: "Table 1.1.: Scalar types" in ELF Application Binary Interface s390x Supplement
230
+ // Version 1.6.1 categorize ISO C char in unsigned integer
231
+ // https://github.com/IBM/s390x-abi/releases/tag/v1.6.1
232
+ // - z/OS: XL C/C++ Language Reference says: "By default, char behaves like an unsigned char."
233
+ // https://www.ibm.com/docs/en/zos/3.1.0?topic=specifiers-character-types
234
+ // Xtensa:
235
+ // - "The char type is unsigned by default for Xtensa processors."
236
+ //
237
+ // On the following operating systems, c_char is signed by default, regardless of architecture.
238
+ // Darwin (macOS, iOS, etc.):
239
+ // Apple targets' c_char is signed by default even on arm
240
+ // https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Handle-data-types-and-data-alignment-properly
241
+ // Windows:
242
+ // Windows MSVC C++ Language Reference says "Microsoft-specific: Variables of type char
243
+ // are promoted to int as if from type signed char by default, unless the /J compilation
244
+ // option is used."
245
+ // https://learn.microsoft.com/en-us/cpp/cpp/fundamental-types-cpp?view=msvc-170#character-types)
246
+ // L4RE:
247
+ // The kernel builds with -funsigned-char on all targets (but useserspace follows the
248
+ // architecture defaults). As we only have a target for userspace apps so there are no
249
+ // special cases for L4RE below.
250
+ all(
251
+ not( windows) ,
252
+ not( target_vendor = "apple" ) ,
253
+ any(
254
+ target_arch = "aarch64" ,
255
+ target_arch = "arm" ,
256
+ target_arch = "csky" ,
257
+ target_arch = "hexagon" ,
258
+ target_arch = "msp430" ,
259
+ target_arch = "powerpc" ,
260
+ target_arch = "powerpc64" ,
261
+ target_arch = "riscv64" ,
262
+ target_arch = "riscv32" ,
263
+ target_arch = "s390x" ,
264
+ target_arch = "xtensa" ,
265
+ )
266
+ ) => {
267
+ pub ( super ) type c_char = u8 ;
268
+ }
269
+ _ => {
270
+ // On every other target, c_char is signed.
271
+ pub ( super ) type c_char = i8 ;
272
+ }
273
+ }
183
274
}
184
275
276
+
185
277
mod c_int_definition {
278
+ #[ cfg( bootstrap) ]
186
279
cfg_if ! {
187
280
if #[ cfg( any( target_arch = "avr" , target_arch = "msp430" ) ) ] {
188
281
pub ( super ) type c_int = i16 ;
@@ -192,9 +285,21 @@ mod c_int_definition {
192
285
pub ( super ) type c_uint = u32 ;
193
286
}
194
287
}
288
+ #[ cfg( not( bootstrap) ) ]
289
+ crate :: cfg_match! {
290
+ any( target_arch = "avr" , target_arch = "msp430" ) => {
291
+ pub ( super ) type c_int = i16 ;
292
+ pub ( super ) type c_uint = u16 ;
293
+ }
294
+ _ => {
295
+ pub ( super ) type c_int = i32 ;
296
+ pub ( super ) type c_uint = u32 ;
297
+ }
298
+ }
195
299
}
196
300
197
301
mod c_long_definition {
302
+ #[ cfg( bootstrap) ]
198
303
cfg_if ! {
199
304
if #[ cfg( all( target_pointer_width = "64" , not( windows) ) ) ] {
200
305
pub ( super ) type c_long = i64 ;
@@ -205,6 +310,18 @@ mod c_long_definition {
205
310
pub ( super ) type c_ulong = u32 ;
206
311
}
207
312
}
313
+ #[ cfg( not( bootstrap) ) ]
314
+ crate :: cfg_match! {
315
+ all( target_pointer_width = "64" , not( windows) ) => {
316
+ pub ( super ) type c_long = i64 ;
317
+ pub ( super ) type c_ulong = u64 ;
318
+ }
319
+ _ => {
320
+ // The minimal size of `long` in the C standard is 32 bits
321
+ pub ( super ) type c_long = i32 ;
322
+ pub ( super ) type c_ulong = u32 ;
323
+ }
324
+ }
208
325
}
209
326
210
327
// N.B., for LLVM to recognize the void pointer type and by extension
0 commit comments