1 个不稳定版本

0.0.0 2020年1月26日

#9#cxx

Download history 432/week @ 2024-04-05 642/week @ 2024-04-12 450/week @ 2024-04-19 441/week @ 2024-04-26 525/week @ 2024-05-03 518/week @ 2024-05-10 462/week @ 2024-05-17 443/week @ 2024-05-24 431/week @ 2024-05-31 476/week @ 2024-06-07 432/week @ 2024-06-14 583/week @ 2024-06-21 442/week @ 2024-06-28 469/week @ 2024-07-05 594/week @ 2024-07-12 439/week @ 2024-07-19

2,070 次每月下载
cxx 中使用

MIT/Apache

2KB

CXX — Rust 和 C++ 之间的安全 FFI

github crates.io docs.rs build status

此库提供了一个 安全 的机制,用于从 Rust 调用 C++ 代码和从 C++ 调用 Rust 代码,不涉及使用 bindgen 或 cbindgen 生成不安全的 C 风格绑定时可能出现的问题。

但这并不意味着 100% 的 C++ 代码都是不安全的。在审计项目时,您需要审计所有不安全的 Rust 代码和 所有 的 C++ 代码。在这种新模式下的核心安全声明是,仅审计 C++ 一侧就足以捕捉所有问题,即 Rust 一侧可以是 100% 安全的。

[dependencies]
cxx = "1.0"

[build-dependencies]
cxx-build = "1.0"

编译器支持:需要 rustc 1.63+ 和 c++11 或更新的版本
发行说明


指南

请参阅 https://cxx.rs 以获取教程、参考资料和示例代码。


概述

我们的想法是,在一个 Rust 模块中(下一节将展示示例)定义我们的 FFI 边界两边的签名,并将其嵌入在一起。基于此,CXX 可以获得完整的边界视图,以对类型和函数签名执行静态分析,以维护 Rust 和 C++ 的不变性和要求。

如果所有静态检查都通过,则 CXX 使用一对代码生成器,在两边同时生成相关的 extern "C" 签名,并在构建过程中稍后添加任何必要的静态断言以验证正确性。在 Rust 一侧,这个代码生成器只是一个属性过程宏。在 C++ 一侧,如果您的构建由 Cargo 管理,则可以是一个小的 Cargo 构建脚本,或者对于 Bazel 或 Buck 等其他构建系统,我们提供了一个命令行工具,该工具生成头文件和源文件,并且应该很容易集成。

生成的 FFI 桥接器在零或可忽略的开销下运行,即没有复制、没有序列化、没有内存分配、不需要运行时检查。

FFI签名可以使用任一端的本机类型,例如Rust的String或C++的std::string,Rust的Box或C++的std::unique_ptr,Rust的Vec或C++的std::vector等,任意组合。CXX保证了ABI兼容的签名,基于关键标准库类型的内置绑定,向另一语言暴露这些类型的惯用API。例如,当从Rust操作C++字符串时,它的len()方法成为调用由C++定义的size()成员函数;当从C++操作Rust字符串时,其size()成员函数调用Rust的len()


示例

在这个示例中,我们正在编写一个希望利用现有C++客户端的大文件blobstore服务的Rust应用程序。这个blobstore支持对不连续缓冲区的put操作进行上传。例如,我们可能正在上传环形缓冲区的快照,这通常由2个块组成,或者由于某些其他原因散布在内存中的文件片段。

此示例的可运行版本位于本存储库的demo目录下。要尝试运行它,请从该目录运行cargo run

#[cxx::bridge]
mod ffi {
    // Any shared structs, whose fields will be visible to both languages.
    struct BlobMetadata {
        size: usize,
        tags: Vec<String>,
    }

    extern "Rust" {
        // Zero or more opaque types which both languages can pass around but
        // only Rust can see the fields.
        type MultiBuf;

        // Functions implemented in Rust.
        fn next_chunk(buf: &mut MultiBuf) -> &[u8];
    }

    unsafe extern "C++" {
        // One or more headers with the matching C++ declarations. Our code
        // generators don't read it but it gets #include'd and used in static
        // assertions to ensure our picture of the FFI boundary is accurate.
        include!("demo/include/blobstore.h");

        // Zero or more opaque types which both languages can pass around but
        // only C++ can see the fields.
        type BlobstoreClient;

        // Functions implemented in C++.
        fn new_blobstore_client() -> UniquePtr<BlobstoreClient>;
        fn put(&self, parts: &mut MultiBuf) -> u64;
        fn tag(&self, blobid: u64, tag: &str);
        fn metadata(&self, blobid: u64) -> BlobMetadata;
    }
}

现在我们只需提供extern "Rust"块中所有内容的Rust定义和extern "C++"块中所有内容的C++定义,然后可以安全地来回调用。

以下是涉及演示的完整源文件集的链接

查看由CXX代码生成器为示例在两种语言中生成的代码的详细信息

   # run Rust code generator and print to stdout
   # (requires https://github.com/dtolnay/cargo-expand)
$ cargo expand --manifest-path demo/Cargo.toml

   # run C++ code generator and print to stdout
$ cargo run --manifest-path gen/cmd/Cargo.toml -- demo/src/main.rs

详细信息

如示例所示,FFI边界的语言涉及3种类型的项

  • 共享结构体 — 它们的字段对两种语言都是可见的。在cxx::bridge中编写的定义是单一的事实来源。

  • 不透明类型 — 它们的字段对另一语言是保密的。这些类型不能通过值在FFI中传递,只能通过间接引用传递,例如引用&、Rust的BoxUniquePtr。根据您的使用情况,可以是任意复杂性的特定语言泛型类型的类型别名。

  • 函数 — 在任一语言中实现,可从另一语言调用。

在CXX桥接的extern "Rust"部分,我们列出了Rust作为真实来源的类型和函数。所有这些都隐式地引用了super模块,即CXX桥接的父模块。你可以将上面示例中的两个项目视为类似于use super::MultiBufuse super::next_chunk,除了它们被重新导出到C++。父模块将直接包含简单事物的定义,或者包含相关的use语句,以便从其他地方引入。

extern "C++"部分,我们列出了C++作为真实来源的类型和函数,以及声明这些API的头文件。在未来,这一部分可能可以通过bindgen风格从头文件中生成,但到目前为止,我们需要写出签名;静态断言将验证它们的准确性。

你的函数实现本身,无论是用C++还是Rust编写的,不需要定义为extern "C" ABI或no_mangle。CXX将在必要时插入正确的shim,使其全部工作。


与bindgen和cbindgen的比较

请注意,在使用CXX时,所有函数签名都有重复:它们在定义实现的地方(在C++或Rust中)被键入一次,然后在cxx::bridge模块内部再次键入。尽管编译时断言保证了它们保持同步,但这与bindgencbindgen不同,在bindgen和cbindgen中,函数签名由人类键入一次,工具在一个语言中消费它们,并在另一个语言中输出。

这是因为CXX扮演着略微不同的角色。在某种程度上,它比bindgen或cbindgen更底层;你可以把它看作是我们所知的extern "C"签名的替代品,而不是bindgen的替代品。在CXX之上构建一个更高层次的bindgen-like工具是合理的,该工具消耗C++头文件和/或Rust模块(和/或类似Thrift的IDL)作为真实来源,并生成cxx::bridge,从而消除重复,同时利用CXX的静态分析安全保证。

但请注意,在其他方面,CXX比bindgens更高层次,具有对常见标准库类型的丰富支持。通常,当我们处理惯用的C++ API时,我们最终会手动将API包装在C样式的原始指针函数中,应用bindgen以获取不安全的原始指针Rust函数,并再次复制API以在Rust中以惯用方式公开它们。这是一种更糟糕的重复形式,因为它从头到尾都是不安全的。

通过使用CXX桥接作为语言之间的共享理解,而不是使用extern "C" C样式签名作为共享理解,常见的FFI用例可以使用100%安全的代码表达。

也可以混合使用,对于您95%的简单FFI,可以使用CXX桥接,而对于剩下的少量特殊签名,则使用传统的bindgen和cbindgen方式。如果CXX的静态限制影响了使用,请提交一个issue,以便我们知道如何让工具更具有表现力。


基于Cargo的设置

对于由Cargo编排的构建,您将使用一个构建脚本,该脚本运行CXX的C++代码生成器,并编译生成的C++代码以及您的crate中的任何其他C++代码。

标准的构建脚本如下。指定的行返回一个cc::Build实例(来自常用的cccrate),您可以在其中设置任何额外的源文件和编译器标志,就像通常一样。

# Cargo.toml

[build-dependencies]
cxx-build = "1.0"
// build.rs

fn main() {
    cxx_build::bridge("src/main.rs")  // returns a cc::Build
        .file("src/demo.cc")
        .std("c++11")
        .compile("cxxbridge-demo");

    println!("cargo:rerun-if-changed=src/main.rs");
    println!("cargo:rerun-if-changed=src/demo.cc");
    println!("cargo:rerun-if-changed=include/demo.h");
}

非Cargo设置

对于Bazel或Buck等非Cargo构建,CXX提供了一个独立命令行工具调用C++代码生成器的替代方法。该工具打包为crates.io上的cxxbridge-cmdcrate,或者可以从本repo的gen/cmd目录中构建。

$ cargo install cxxbridge-cmd

$ cxxbridge src/main.rs --header > path/to/mybridge.h
$ cxxbridge src/main.rs > path/to/mybridge.cc

安全性

请注意,该库的设计是有意限制性的和有偏见的!我们的目标不是足够强大以处理两种语言中的任意签名。相反,该项目旨在确定一个合理表达的功能集,我们可以就其提供有用的安全性保证,并可能在将来扩展。您可能会发现,要有效地使用CXX桥接需要一些实践,因为它不会以您习惯的方式工作。

确保安全性的考虑因素包括

  • 设计上,我们的成对代码生成器协同工作,控制FFI边界的两侧。在Rust中,通常编写自己的extern "C"块是不安全的,因为Rust编译器无法知道您所写的签名是否与另一语言中实现的签名匹配。使用CXX,我们实现了这种可见性并知道另一边的样子。

  • 我们的静态分析可以检测并防止从C++向Rust传递不应按值传递的类型,例如,因为这些类型可能包含Rust的移动行为会破坏的内部指针。

  • 出人意料的是,Rust中的struct和C++中的struct可以具有完全相同的布局/字段/对齐/一切,但在按值传递时仍可能不是相同的ABI。这是bindgen的一个长期存在的bug,会导致看似完全正确的代码出现段错误(rust-lang/rust-bindgen#778)。CXX了解这一点,可以在需要的地方透明地插入必要的零成本解决方案,因此您可以放心地按值传递struct。这是通过拥有边界的两边而不是一边来实现的。

  • 模板实例化:例如,为了在Rust中暴露由真实的C++ unique_ptr支持的UniquePtr类型,我们有一种使用Rust特质将行为连接到另一语言执行的模板实例化的方式。


内置类型

除了所有原始类型(i32 <=> int32_t)之外,以下常用类型可用于共享struct的字段以及函数的参数和返回值。

Rust中的名称C++中的名称限制
Stringrust::String
&strrust::Str
&[T]rust::Slice<const T>不能包含不透明的C++类型
&mut [T]rust::Slice<T>不能包含不透明的C++类型
CxxStringstd::string不能按值传递
Box<T>rust::Box<T>不能包含不透明的C++类型
UniquePtr<T>std::unique_ptr<T>无法容纳不透明Rust类型
SharedPtrstd::shared_ptr无法容纳不透明Rust类型
[T; N]std::array不能包含不透明的C++类型
Vecrust::Vec不能包含不透明的C++类型
CxxVectorstd::vector不能按值传递,无法容纳不透明Rust类型
*mut T, *const TT*, const T*具有原始指针参数的函数必须声明为unsafe才能调用
fn(T, U) -> Vrust::Fn目前只实现了从Rust传递到C++
Resultthrow/catch仅允许作为返回类型

此项目中rust命名空间C++ API由include/cxx.h文件定义。您需要在C++代码中使用这些类型时包含此头文件。

以下类型计划在“不久的将来”得到支持,但尚未实现。我不认为这些实现有任何困难,但需要为每种类型设计一个良好的API。

Rust中的名称C++中的名称
BTreeMap待定
HashMap待定
Arc待定
Option待定
待定std::map
待定std::unordered_map

剩余工作

CXX仍处于早期阶段;我将其作为一个最小可行产品发布,以收集对方向和邀请协作者的反馈。请检查开放问题。

特别是,如果您在构建或链接这些内容时遇到问题,请特别报告这些问题。我相信有方法可以使构建方面更加友好或更健壮。

最后,我对Rust库设计比C++库设计更了解,因此如果有人有任何建议,我将很乐意帮助使此项目的C++ API更加符合习惯。


许可证

根据您的选择,许可协议为Apache License, Version 2.0或MIT许可。请参阅Apache License, Version 2.0MIT license
除非您明确声明,否则根据Apache-2.0许可定义,您有意提交的任何贡献,均应双许可如上所述,无需任何附加条款或条件。

无运行时依赖