rust - Rust 如何调用处理 C 'int' 的 API？

Question

Rust 拥有一组清晰有序的有符号和无符号整数类型，而不是 C 几十年来积累的杂乱无章的整数类型集合，例如用于有符号 32 位整数的 i32；在大多数平台上，这也是 C 的 int 所表示的，尽管 C 并不保证这一点。

当 Rust 尝试调用一个定义的 API，不是按照绝对整数大小，而是按照“C int，无论这个平台上是什么”定义时，会发生什么？例如，经典的 Unix 文件 I/O(read、write 等)，通过小整数来标识文件；在大多数平台上，这些都是有符号的 32 位整数，但可移植 C 代码通常将它们称为 int (而不是 int32_t)，因为这就是 API 的定义方式；至少在理论上是可能的，例如 future 的操作系统可能会将 int 定义为 64 位，并附带该 API。

可移植的 Rust 代码如何处理它？它是否只是采取 i32 与当今使用的平台相匹配的态度，这就足够了？或者它还有其他作用吗？

Answer 1

What happens when Rust is trying to call an API defined, not in terms of an absolute integer size, but in terms of "C int, whatever that may be on this platform"?

Rust 定义了 c_int 类型和各种其他 C type aliases used in FFI declarations在 raw::os 命名空间中支持这一点。该模块使用 cfg 指令来检测平台和架构，并且 define these types适本地匹配等效的 C 类型。这些存在于 int、long 等。

这样，通过使用这些中性声明，您的代码在 C 的 int 可能会有所不同的不同平台上重建时仍可移植。

How does portable Rust code handle it? Does it just take the attitude that i32 matches the platforms in use today, and that's good enough? Or does it do something else?

The libc module defines its own c_int这确实假设是 i32，大概是出于历史原因。有an interesting RFC which details libc及其演变。

it is at least theoretically possible that e.g. a future operating system might define int as 64-bit

当然；在这种情况下，可以为此操作系统添加 #cfg[] 子句，使其成为 64 位，从而保留模块的源兼容性。