我应该使用libc::c_char还是std::os::raw::c_char？

Question

我正在为Rust编写一个FFI包装器。我看到了libc::c_char和std::os::raw::c_char的用法。我的C语言知识非常有限，不知道这两者之间是否有区别。如果我想通过cffi将字符串暴露给Python，应该使用哪个？

- colinfang

---

我的C语言知识非常有限，我想知道是否有任何区别。为什么C语言要关心这个呢？这是关于Rust的。显然这描述的是同一件事情。在C语言中，char代表一个字符。 - Stargateur

Answer 1

我无法回答哪个更惯用，但我可以说它们在64位Linux上相同（大多数在线托管文档的默认平台）：

std::os::raw::c_char：

type c_char = i8;

libc::c_char:

type c_char = i8;

对于跨不同平台的更广泛考虑会更加复杂。标准库 紧密地组织了c_char的所有定义，但libc则按平台分组。考虑到这种类型的基本性质，我期望它们在所有平台上都是相同的。

实际上，这些定义都不太可能改变，因此可能没有稳定性差异。

我的建议是在需要使用libc中的特定内容之前，先使用标准库版本的，然后在需要时将所有类型切换为libc的变量，以保持一致性。

- Shepmaster

Answer 2

除了@Shepmaster的答案之外，我想强调一个事实，即libc不依赖于std。

因此，如果您不能使用std，则必须使用libc。可以在此处查看此情况here。

目前，默认情况下libc链接到标准库，但如果您希望在#![no_std]情况或crate中使用libc，则可以通过以下方式请求：

[dependencies]
libc = { version = "0.2", default-features = false }

- Centril

Answer 3

自从Rust 1.64版本以来，模块专门用于FFI中提供了c_char：std::ffi::c_char，甚至还有core::ffi::c_char。

它是Rust提供的，因此不依赖于像libc这样的外部库，同时也在core中可用，因此在no_std环境中也可用。

如果您不需要支持早期的Rust版本，这应该是最符合惯用法的选择。

- cafce25