如何将非可变引用从 Rust 传递给不使用 const 的 C-API即使它应该使用？

如何解决如何将非可变引用从 Rust 传递给不使用 const 的 C-API即使它应该使用？

我有一个 C-API 的包装器：

#[repr(transparent)]
pub struct Request(http_request_t);

这个包装器提供了几种与请求交互的方法：

impl Request {
    pub fn bytes_received(&self) -> usize {
        unsafe {
            http_request_bytes_received(&self.0 as *const http_request_t)
        }
    }
}

不幸的是，C-API 对 const-correctness 没有那么严格，因此具有 usize http_request_bytes_received(*http_request_t) 的类型签名，它由 bindgen 尽职地转换为 http_request_bytes_received(*mut http_request_t) -> usize。

现在我可以摆脱这种情况了，但是从 &T 转换到 *mut T 可以 easily lead to undefined behaviour（这是一个令人讨厌的转换）。但它可能没问题，因为 http_request_bytes_received 不会改变 http_request_t。

一种可能的替代方法是使用 UnsafeCell，因此 http_request_t 是内部可变的：

#[repr(transparent)]
pub struct Request(UnsafeCell<http_request_t>);

impl Request {
    pub fn bytes_received(&self) -> usize {
        unsafe {
            http_request_bytes_received(self.0.get())
        }
    }
}

这种方法是否合理？是否有任何严重的缺点？

（我想它可能会限制一些 Rust 优化，并使 Request !Sync）

解决方法

简短回答：只需将其转换为 *mut T 并将其传递给 C。

长答案：

最好先了解为什么将 *const T 转换为 *mut T 容易出现未定义的行为。

Rust 的内存模型确保 &mut T 不会与其他任何东西别名，因此编译器可以自由地完全破坏 T 然后恢复其内容，而程序员无法观察到这种行为。如果 &mut T 和 &T 共存并指向同一位置，则会出现未定义的行为，因为如果在编译器破坏 &T 时从 &mut T 读取会发生什么？类似地，如果您有 &T，编译器假定没有人会修改它（通过 UnsafeCell 的内部可变性除外），如果它指向的内存被修改，则会出现未定义的行为。

根据背景，很容易理解为什么 *const T 到 *mut T 是危险的——您不能取消引用结果指针。如果您曾经取消引用 *mut T，您就获得了一个 &mut T，它将是 UB。但是，转换操作本身是安全的，您可以安全地将 *mut T 转换回 *const T 并取消引用它。

这是 Rust 语义；在 C 端，关于 T* 的保证很弱。如果您持有 T*，编译器不能假设没有共享者。事实上，编译器甚至不能断言它指向有效地址（它可能是空指针或越后指针）。除非代码显式写入指针，否则 C 编译器无法生成存储指令到内存位置。

T* 在 C 端的弱含义意味着它不会违反 Rust 关于 &T 语义的假设。您可以安全地将 &T 强制转换为 *mut T 并将其传递给 C，前提是 C 端从不修改指针指向的内存。

请注意，您可以指示 C 编译器该指针不会与 T * restrict 的其他任何内容进行别名，但是由于您提到的 C 代码对 const 的正确性并不严格，它可能确实如此也不要使用 restrict。