1//! Compatibility module for C platform-specific types. Use [`core::ffi`] instead.
23#![stable(feature = "raw_os", since = "1.1.0")]
45#[cfg(test)]
6mod tests;
78macro_rules!alias_core_ffi {
9 ($($t:ident)*) => {$(
10#[stable(feature = "raw_os", since = "1.1.0")]
11 #[doc = include_str!(concat!("../../../../core/src/ffi/", stringify!($t), ".md"))]
12// #[doc(cfg(all()))] // commented out for std.noratrieb.dev
13pub type $t = core::ffi::$t;
14 )*}
15}
1617#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `char` type.\n\n[C\'s `char` type] is completely unlike [Rust\'s `char` type]; while Rust\'s type represents a unicode scalar value, C\'s `char` type is just an ordinary integer. On modern architectures this type will always be either [`i8`] or [`u8`], as they use byte-addressed memory with 8-bit bytes.\n\nC chars are most commonly used to make C strings. Unlike Rust, where the length of a string is included alongside the string, C strings mark the end of a string with the character `\'\\0\'`. See `CStr` for more information.\n\n[C\'s `char` type]: https://en.wikipedia.org/wiki/C_data_types#Basic_types\n[Rust\'s `char` type]: char\n"]
pub type c_char = core::ffi::c_char;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `signed char` type.\n\nThis type will always be [`i8`], but is included for completeness. It is defined as being a signed integer the same size as a C [`char`].\n\n[`char`]: c_char\n"]
pub type c_schar = core::ffi::c_schar;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `unsigned char` type.\n\nThis type will always be [`u8`], but is included for completeness. It is defined as being an unsigned integer the same size as a C [`char`].\n\n[`char`]: c_char\n"]
pub type c_uchar = core::ffi::c_uchar;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `signed short` (`short`) type.\n\nThis type will almost always be [`i16`], but may differ on some esoteric systems. The C standard technically only requires that this type be a signed integer with at least 16 bits; some systems may define it as `i32`, for example.\n"]
pub type c_short = core::ffi::c_short;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `unsigned short` type.\n\nThis type will almost always be [`u16`], but may differ on some esoteric systems. The C standard technically only requires that this type be an unsigned integer with the same size as a [`short`].\n\n[`short`]: c_short\n"]
pub type c_ushort = core::ffi::c_ushort;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `signed int` (`int`) type.\n\nThis type will almost always be [`i32`], but may differ on some esoteric systems. The C standard technically only requires that this type be a signed integer that is at least the size of a [`short`]; some systems define it as an [`i16`], for example.\n\n[`short`]: c_short\n"]
pub type c_int = core::ffi::c_int;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `unsigned int` type.\n\nThis type will almost always be [`u32`], but may differ on some esoteric systems. The C standard technically only requires that this type be an unsigned integer with the same size as an [`int`]; some systems define it as a [`u16`], for example.\n\n[`int`]: c_int\n"]
pub type c_uint = core::ffi::c_uint;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `signed long` (`long`) type.\n\nThis type will always be [`i32`] or [`i64`]. Most notably, many Linux-based systems assume an `i64`, but Windows assumes `i32`. The C standard technically only requires that this type be a signed integer that is at least 32 bits and at least the size of an [`int`], although in practice, no system would have a `long` that is neither an `i32` nor `i64`.\n\n[`int`]: c_int\n"]
pub type c_long = core::ffi::c_long;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `unsigned long` type.\n\nThis type will always be [`u32`] or [`u64`]. Most notably, many Linux-based systems assume a `u64`, but Windows assumes `u32`. The C standard technically only requires that this type be an unsigned integer with the size of a [`long`], although in practice, no system would have a `ulong` that is neither a `u32` nor `u64`.\n\n[`long`]: c_long\n"]
pub type c_ulong = core::ffi::c_ulong;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `signed long long` (`long long`) type.\n\nThis type will almost always be [`i64`], but may differ on some systems. The C standard technically only requires that this type be a signed integer that is at least 64 bits and at least the size of a [`long`], although in practice, no system would have a `long long` that is not an `i64`, as most systems do not have a standardised [`i128`] type.\n\n[`long`]: c_long\n"]
pub type c_longlong = core::ffi::c_longlong;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `unsigned long long` type.\n\nThis type will almost always be [`u64`], but may differ on some systems. The C standard technically only requires that this type be an unsigned integer with the size of a [`long long`], although in practice, no system would have a `long long` that is not a `u64`, as most systems do not have a standardised [`u128`] type.\n\n[`long long`]: c_longlong\n"]
pub type c_ulonglong = core::ffi::c_ulonglong;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `float` type.\n\nThis type will almost always be [`f32`], which is guaranteed to be an [IEEE 754 single-precision float] in Rust. That said, the standard technically only guarantees that it be a floating-point number, and it may have less precision than `f32` or not follow the IEEE-754 standard at all.\n\n[IEEE 754 single-precision float]: https://en.wikipedia.org/wiki/IEEE_754\n"]
pub type c_float = core::ffi::c_float;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `double` type.\n\nThis type will almost always be [`f64`], which is guaranteed to be an [IEEE 754 double-precision float] in Rust. That said, the standard technically only guarantees that it be a floating-point number with at least the precision of a [`float`]; some 16-bit systems use [`f32`], for example. Esoteric systems could use something entirely different from the IEEE-754 standard.\n\n[IEEE 754 double-precision float]: https://en.wikipedia.org/wiki/IEEE_754\n[`float`]: c_float\n"]
pub type c_double = core::ffi::c_double;
#[stable(feature = "raw_os", since = "1.1.0")]
#[doc =
"Equivalent to C\'s `void` type when used as a [pointer].\n\nIn essence, `*const c_void` is equivalent to C\'s `const void*`\nand `*mut c_void` is equivalent to C\'s `void*`. That said, this is\n*not* the same as C\'s `void` return type, which is Rust\'s `()` type.\n\nTo model pointers to opaque types in FFI, until `extern type` is\nstabilized, it is recommended to use a newtype wrapper around an empty\nbyte array. See the [Nomicon] for details.\n\nOne could use `std::os::raw::c_void` if they want to support old Rust\ncompilers down to 1.1.0. After Rust 1.30.0, it was re-exported by\nthis definition. For more information, please read [RFC 2521].\n\n[Nomicon]: https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs\n[RFC 2521]: https://github.com/rust-lang/rfcs/blob/master/text/2521-c_void-reunification.md\n"]
pub type c_void = core::ffi::c_void;alias_core_ffi! {
18c_charc_scharc_uchar19c_shortc_ushort20c_intc_uint21c_longc_ulong22c_longlongc_ulonglong23c_float24c_double25c_void26}