rust语言c_int变迁史

在 Rust的开发标准中，std::ffi::c_int，std::os::raw::c_int和core::ffi::c_int这三个类型虽然在大多数平台上指向相同的底层数据类型，但在语义、演进路径和适用环境上有所不同。

1. 核心区别与关系

类型	模块位置	引入版本	适用场景 (2025 标准)
core::ffi::c_int	core	1.64 (稳定)	最基础定义。适用于 no_std (嵌入式/内核) 环境。
std::ffi::c_int	std	1.64 (稳定)	标准库别名。最常用的 FFI 类型，属于 std 的一部分。
std::os::raw::c_int	std::os	1.1 (旧版)	过时的旧位置。为了向后兼容保留，不建议新代码使用。

2. 为什么会有三个？（演进历史）

1. 早期阶段 (std::os::raw):
   最初，Rust 将 C 类型放在 std::os::raw 下。但这种设计不合理，因为 int 并不是特定于操作系统的“原始属性”，而是 FFI 交互的通用需求。
2. 标准化阶段 (core::ffi & std::ffi):
   为了支持 no_std（例如编写操作系统内核或嵌入式固件），Rust 团队在 2022 年左右（1.64版本）将 C 类型移动到了 core::ffi 中。同时在 std::ffi 下建立了同名别名。

3. 开发建议 

最佳实践：使用 std::ffi::c_int 或 core::ffi::c_int

如果你正在编写一个通用的 FFI 接口（例如为 C 语言编写 Rust 插件），应该根据你的项目环境选择：

• 普通应用/库：使用 std::ffi::c_int。它更符合 std 优先的习惯。
• 底层/嵌入式库：使用 core::ffi::c_int。这样你的库可以在没有操作系统支持的环境下运行。

应当避免：std::os::raw::c_int

虽然它依然有效且不会报错，但它已被视为旧式写法。现代 IDE（如 Rust-analyzer）和 Clippy 通常会建议你迁移到 std::ffi。

4. 它们在底层真的完全一样吗？

答案是肯定的。 在源代码层面，它们通过别名机制链接在一起：

// std/src/ffi/mod.rs
#[doc(inline)]
pub use core::ffi::c_int;

// std/src/os/raw/mod.rs
#[deprecated(since = "1.64.0", note = "use `core::ffi` or `std::ffi` instead")]
pub type c_int = core::ffi::c_int;

5. 与 i32 的转换

无论使用哪一个，它们都不能直接隐式转换为 i32，必须进行显式转换：

use std::ffi::c_int;

let rust_num: i32 = 42;
let c_num: c_int = rust_num as c_int; // 显式转换以保证安全

小结： 建议统一使用 std::ffi::c_int（有标准库时）或 core::ffi::c_int（无标准库时），彻底停用 std::os::raw。