rust - 库应该向消费者公开 c_int 还是强制 i32 兼容性

Question

我正在 C++ 库上编写一个简单的 Rust 包装器。这个库是使用原生 int 类型编写的。而且我不知道通过 Rust 公开这些 API 的最佳方法是什么。这里我们有两个考虑:

1. 库只是 C++ 代码的包装器，我们没有责任检查 int 大小。因此，只需在我们的高级接口(interface)中公开 c_int。

2. 高级接口(interface)必须使用原生 Rust 类型，例如 i32，因此我们在任何地方都使用它，同时静态检查 int 是 i32 通过一些健康检查，例如

#[allow(unused)]
fn assert_32_bit() {
    let _: c_int = 0_i32;
}

后者只是禁止用户在任何 int 不是 i32 的地方使用这个库。

我已经阅读了 nomicon 关于这个问题的意见 ( link )，它的意见是:

The raw C API needs to be wrapped to provide memory safety and make use of higher-level concepts like vectors.

但所有使用safe wrappers 的示例都使用int32_t 和类似的类型，它们很容易映射到Rust 类型系统。

我应该采用哪种方法，为什么？官方社区对这个问题的立场是什么？

例如，这里是示例 C++ 函数:

int sum(int a, int b);

我应该写吗

fn high_level_api_sum(a: c_int, b: c_int) { unsafe {sum(a, b)} }

或

fn high_level_api_sum(a: i32, b: i32) { unsafe {sum(a, b)} }

#[allow(unused)]
fn assert_32_bit() {
    let _: c_int = 0_i32;
}

Answer 1

我认为在这方面没有任何类似“官方”的立场。接下来是意见......也许首先暗示这个问题不适合 SO。

如果正确的类型是c_int，则使用c_int。 Rust 程序员不应该如此脆弱，以至于仅仅因为你在到 C/C++ 库的接口(interface)中使用 C 类型，他们就会蜷缩成胎儿的姿势。

问问自己:您的用户是否从您锁定 c_int 不是 i32 的所有潜在平台中受益(例如嵌入式平台)？

如果答案是“他们不这样做”，那么就不要这样做。如果他们确实以某种方式受益，那么，您将不得不权衡一下自己是否锁定平台。也许 c_int 的使用会带来某种更广泛的接口(interface)问题。