add unsafe的五种兵器

3 years ago · a8166bd637
parent 3fb529e2a1
commit a8166bd637
4 changed files with 340 additions and 7 deletions
--- a/book/contents/SUMMARY.md
+++ b/book/contents/SUMMARY.md
@ -86,8 +86,7 @@
    - [全局变量](advance/global-variable.md)
    - [错误处理](advance/errors.md)
    - [Unsafe Rust](advance/unsafe/intro.md)
-      - [原生指针 doing](advance/unsafe/raw-pointer.md)
-      - [FFI todo](advance/unsafe/ffi.md)
+      - [五种兵器](advance/unsafe/superpowers.md)
    <!-- - [高阶特征约束(HRTB) todo](advance/hrtb.md) -->

 ## 专题内容,每个专题都配套一个小型项目进行实践
--- a/book/contents/advance/unsafe/ffi.md
+++ b/book/contents/advance/unsafe/ffi.md
@ -1,4 +0,0 @@
-# FFI外部语言用
-
-
-https://www.reddit.com/r/rust/comments/s3x1e3/const_const_u8/
--- a/book/contents/advance/unsafe/raw-pointer.md
+++ b/book/contents/advance/unsafe/raw-pointer.md
@ -1 +0,0 @@
-# raw pointer
--- a/book/contents/advance/unsafe/superpowers.md
+++ b/book/contents/advance/unsafe/superpowers.md
@ -0,0 +1,339 @@
+# 五种兵器
+在[上文](https://course.rs/advance/unsafe/intro.html)中，我们提到了 `unsafe` 在 Rust 中拥有的五种超能力，下面一起来看看。
+
+## 解引用原生指针
+原生指针(raw pointer) 又称裸指针，在功能上跟引用类似，同时它也需要显式地注明可变性。但是又和引用有所不同，原生指针长这样: `*const T` 和 `*mut T`，它们分别代表了不可变和可变。
+
+大家在之前学过 `*` 操作符，知道它可以用于解引用，但是在原生指针 `*const T` 中，这里的 `*` 只是类型名称的一部分，并没有解引用的含义。
+
+至此，我们已经学过三种类似指针的概念：引用、智能指针和原生指针。与前两者不同，原生指针：
+
+- 可以绕过 Rust 的借用规则，可以同时拥有一个数据的可变、不可变指针，甚至还能拥有多个可变的指针
+- 并不能保证指向合法的内存
+- 可以是 `null`
+- 没有实现任何自动的回收 (drop)
+
+总之，原生指针跟 C 指针是非常像的，使用它需要以牺牲安全性为前提，但我们获得了更好的性能，也可以跟其它语言或硬件打交道。
+
+#### 基于引用创建原生指针
+下面的代码**基于值的引用**同时创建了可变和不可变的原生指针：
+```rust
+let mut num = 5;
+
+let r1 = &num as *const i32;
+let r2 = &mut num as *mut i32;
+```
+
+`as` 可以用于强制类型转换，在[之前章节](https://course.rs/basic/converse.html)中有讲解。在这里，我们将引用 `&num / &mut num` 强转为相应的原生指针 `*const i32 / *mut i32`。
+
+细心的同学可能会发现，在这段代码中并没有 `unsafe` 的身影，原因在于：**创建原生指针是安全的行为，而解引用原生指针才是不安全的行为** :
+```rust
+fn main() {
+    let mut num = 5;
+
+    let r1 = &num as *const i32;
+
+    unsafe {
+        println!("r1 is: {}", *r1);
+    }
+}
+```
+
+#### 基于内存地址创建原生指针
+在上面例子中，我们基于现有的引用来创建原生指针，这种行为是很安全的。但是接下来的方式就不安全了：
+```rust
+let address = 0x012345usize;
+let r = address as *const i32;
+```
+
+这里基于一个内存地址来创建原生指针，可以想像，这种行为是相当危险的。试图使用任意的内存地址往往是一种未定义的行为(undefined behavior)，因为该内存地址有可能存在值，也有可能没有，就算有值，也大概率不是你需要的值。
+
+同时编译器也有可能会优化这段代码，会造成没有任何内存访问发生，甚至程序还可能发生段错误(segmentation fault)。**总之，你几乎没有好的理由像上面这样实现代码，虽然它是可行的**。
+
+如果真的要使用内存地址，也是类似下面的用法，先取地址，再使用，而不是凭空捏造一个地址：
+```rust
+use std::{slice::from_raw_parts, str::from_utf8_unchecked};
+
+// 获取字符串的内存地址和长度
+fn get_memory_location() -> (usize, usize) {
+  let string = "Hello World!";
+  let pointer = string.as_ptr() as usize;
+  let length = string.len();
+  (pointer, length)
+}
+
+// 在制定的内存地址读取字符串
+fn get_str_at_location(pointer: usize, length: usize) -> &'static str {
+  unsafe { from_utf8_unchecked(from_raw_parts(pointer as *const u8, length)) }
+}
+
+fn main() {
+  let (pointer, length) = get_memory_location();
+  let message = get_str_at_location(pointer, length);
+  println!(
+    "The {} bytes at 0x{:X} stored: {}",
+    length, pointer, message
+  );
+  // 如果大家想知道为何处理原生指针需要 `unsafe`，可以试着反注释以下代码
+  // let message = get_str_at_location(1000, 10);
+}
+```
+
+以上代码同时还演示了访问非法内存地址会发生什么，大家可以试着去反注释这段代码试试。
+
+#### 使用 * 解引用
+```rust
+let a = 1;
+let b: *const i32 = &a as *const i32; 
+let c: *const i32 = &a;
+unsafe {
+    println!("{}", *c);
+}
+```
+
+使用 `*` 可以对原生指针进行解引用，由于该指针的内存安全性并没有任何保证，因此我们需要使用 `unsafe` 来包裹解引用的逻辑(切记，`unsafe` 语句块的范围一定要尽力的小，具体原因在上一章节有讲)。
+
+以上代码另一个值得注意的点就是：除了使用 `as` 来显式的转换，我们还使用了隐式的转换方式 `let c: *const i32 = &a;`。在实际使用中，我们建议使用 `as` 来转换，因为这种显式的方式更有助于提醒用户：你在使用的指针是原生指针，需要小心。
+
+#### 基于智能指针创建原生指针
+还有一种创建原生指针的方式，那就是基于智能指针来创建:
+```rust
+let a: Box<i32> = Box::new(10);
+// 需要先解引用a
+let b: *const i32 = &*a;
+// 使用 into_raw 来创建
+let c: *const i32 = Box::into_raw(a);
+```
+
+#### 小结
+像之前代码演示的那样，使用原生指针可以让我们创建两个可变指针都指向同一个数据，如果使用安全的Rust，你是无法做到这一点的，违背了借用规则，编译器会对我们进行无情的阻止。因此原生指针可以绕过借用规则，但是由此带来的数据竞争问题，就需要大家自己来处理了，总之，需要小心！
+
+既然这么危险，为何还要使用原生指针？除了之前提到的性能等原因，还有一个重要用途就是跟 `C` 语言的代码进行交互( FFI )，在讲解 FFI 之前，先来看看如何调用 unsafe 函数或方法。
+
+## 调用 unsafe 函数或方法
+`unsafe` 函数从外表上来看跟普通函数并无区别，唯一的区别就是它需要使用 `unsafe fn` 来进行定义。这种定义方式是为了告诉调用者：当调用此函数时，你需要注意它的相关需求，因为 Rust 无法担保调用者在使用该函数时能满足它所需的一切需求。
+
+强制调用者加上 `unsafe` 语句块，就可以让他清晰的认识到，正在调用一个不安全的函数，需要小心看看文档，看看函数有哪些特别的要求需要被满足。
+
+```rust
+unsafe fn dangerous() {}
+fn main() {
+    dangerous();
+}
+```
+
+如果试图像上面这样调用，编译器就会报错：
+```shell
+error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
+ --> src/main.rs:3:5
+  |
+3 |     dangerous();
+  |     ^^^^^^^^^^^ call to unsafe function
+```
+
+按照报错提示，加上 `unsafe` 语句块后，就能顺利执行了:
+```rust
+unsafe {
+    dangerous();
+}
+```
+
+道理很简单，但一定要牢记在心：**使用 unsafe 声明的函数时，一定要看看相关的文档，确定自己没有遗漏什么**。
+
+还有，`unsafe` 无需俄罗斯套娃，在 `unsafe` 函数体中使用 `unsafe` 语句块是多余的行为。
+
+## 用安全抽象包裹 unsafe 代码
+一个函数包含了 `unsafe` 代码不代表我们需要将整个函数都定义为 `unsafe fn`。事实上，在标准库中有大量的安全函数，它们内部都包含了 `unsafe` 代码块，下面我们一起来看看一个很好用的标准库函数：`split_at_mut`。
+
+大家可以想象一下这个场景：需要将一个数组分成两个切片，且每一个切片都要求可变的。类似需求在安全 Rust 中是很难实现的，因为要对同一个数组做两个可变借用：
+```rust
+fn split_at_mut(slice: &mut [i32], mid: usize) -> (&mut [i32], &mut [i32]) {
+    let len = slice.len();
+
+    assert!(mid <= len);
+
+    (&mut slice[..mid], &mut slice[mid..])
+}
+
+fn main() {
+    let mut v = vec![1, 2, 3, 4, 5, 6];
+
+    let r = &mut v[..];
+
+    let (a, b) = r.split_at_mut(3);
+
+    assert_eq!(a, &mut [1, 2, 3]);
+    assert_eq!(b, &mut [4, 5, 6]);
+}
+```
+
+上面代码一眼看过去就知道会报错，因为我们试图在自定义的 `split_at_mut` 函数中，可变借用 `slice` 两次：
+```shell
+error[E0499]: cannot borrow `*slice` as mutable more than once at a time
+ --> src/main.rs:6:30
+  |
+1 | fn split_at_mut(slice: &mut [i32], mid: usize) -> (&mut [i32], &mut [i32]) {
+  |                        - let's call the lifetime of this reference `'1`
+...
+6 |     (&mut slice[..mid], &mut slice[mid..])
+  |     -------------------------^^^^^--------
+  |     |     |                  |
+  |     |     |                  second mutable borrow occurs here
+  |     |     first mutable borrow occurs here
+  |     returning this value requires that `*slice` is borrowed for `'1`
+```
+
+对于 Rust 的借用检查器来说，它无法理解我们是分别借用了同一个切片的两个不同部分，但事实上，这种行为是没任何问题的，毕竟两个借用没有任何重叠之处。总之，不太聪明的 Rust 编译器阻碍了我们用这种简单且安全的方式去实现，那只能剑走偏锋，试试 `unsafe` 了。
+
+```rust
+use std::slice;
+
+fn split_at_mut(slice: &mut [i32], mid: usize) -> (&mut [i32], &mut [i32]) {
+    let len = slice.len();
+    let ptr = slice.as_mut_ptr();
+
+    assert!(mid <= len);
+
+    unsafe {
+        (
+            slice::from_raw_parts_mut(ptr, mid),
+            slice::from_raw_parts_mut(ptr.add(mid), len - mid),
+        )
+    }
+}
+```
+
+相比安全实现，这段代码就显得没那么好理解了，甚至于我们还需要像 C 语言那样，通过指针地址的偏移去控制数组的分割。
+
+- `as_mut_ptr` 会返回指向 `slice` 首地址的原生指针 `*mut i32`
+- `slice::from_raw_parts_mut` 函数通过指针和长度来创建一个新的切片，简单来说，该切片的初始地址是 `ptr`，长度为 `mid`
+- `ptr.add(mid)` 可以获取第二个切片的初始地址，由于切片中的元素是 `i32` 类型，每个元素都占用了 4 个字节的内存大小，因此我们不能简单的用 `ptr + mid` 来作为初始地址，而应该使用 `ptr + 4 * mid`，但是这种使用方式并不安全，因此 `.add` 方法是最佳选择
+
+
+由于 `slice::from_raw_parts_mut` 使用原生指针作为参数，因此它是一个 `unsafe fn`，我们在使用它时，就必须用 `unsafe` 语句块进行包裹，类似的，`.add` 方法也是如此(还是那句话，不要将无关的代码包含在 `unsafe` 语句块中)。
+
+部分同学可能会有疑问，那这段代码我们怎么保证 `unsafe` 中使用的原生指针 `ptr` 和 `ptr.add(mid)` 是合法的呢？秘诀就在于 `assert!(mid <= len);` ，通过这个断言，我们保证了原生指针一定指向了 `slice` 切片中的某个元素，而不是一个莫名其妙的内存地址。
+
+再回到我们的主题：**虽然 split_at_mut 使用了 `unsafe`，但我们无需将其声明为 `unsafe fn`**，这种情况下就是使用安全的抽象包裹 `unsafe` 代码，这里的 `unsafe` 使用是非常安全的，因为我们从合法数据中创建了的合法指针。
+
+与之对比，下面的代码就非常危险了:
+```rust
+use std::slice;
+
+let address = 0x01234usize;
+let r = address as *mut i32;
+
+let slice: &[i32] = unsafe { slice::from_raw_parts_mut(r, 10000) };
+println!("{:?}",slice);
+```
+
+这段代码从一个任意的内存地址，创建了一个 10000 长度的 `i32` 切片，我们无法保证切片中的元素都是合法的 `i32` 值，这种访问就是一种未定义行为(UB = undefined behavior)。
+
+```shell
+zsh: segmentation fault
+```
+
+不出所料，运行后看到了一个段错误。
+
+## FFI
+`FFI`（Foreign Function Interface）可以用来与其它语言进行交互，但是并不是所有语言都这么称呼，例如 Java 称之为 `JNI（Java Native Interface）`。
+
+`FFI` 之所以存在是由于现实中很多代码库都是由不同语言编写的，如果我们需要使用某个库，但是它是由其它语言编写的，那么往往只有两个选择：
+
+- 对该库进行重写或者移植
+- 使用 `FFI`
+
+前者相当不错，但是在很多时候，并没有那么多时间去重写，因此 `FFI` 就成了最佳选择。回到 Rust 语言上，由于这门语言依然很年轻，一些生态是缺失的，我们在写一些不是那么大众的项目时，可能会同时遇到没有相应的 Rust 库可用的尴尬境况，此时通过 `FFI` 去调用 C 语言的库就成了相当棒的选择。
+
+还有在将 C/C++ 的代码重构为时，先将相关代码引入到 Rust 项目中，然后逐步重构，也是不错的(为什么用不错来形容？因为重构一个有一定规模的 C/C++ 项目远没有想象中美好，因此最好的选择还是对于新项目使用 Rust 实现，老项目。。就让它先运行着吧)。
+
+当然，除了 `FFI` 还有一个办法可以解决跨语言调用的问题，那就是将其作为一个独立的服务，然后使用网络调用的方式去访问，HTTP，gRPC都可以。
+
+言归正传，之前我们提到 `unsafe` 的另一个重要目的就是对 `FFI` 提供支持，它的全称是 `Foreign Function Interface`，顾名思义，通过 `FFI` , 我们的 Rust 代码可以跟其它语言的外部代码进行交互。
+
+下面的例子演示了如何调用 C 标准库中的 `abc` 函数：
+```rust
+extern "C" {
+    fn abs(input: i32) -> i32;
+}
+
+fn main() {
+    unsafe {
+        println!("Absolute value of -3 according to C: {}", abs(-3));
+    }
+}
+```
+
+C 语言的代码定义在了 `extern` 代码块中， 而 `extern` 必须使用 `unsafe` 才能进行进行调用，原因在于其它语言的代码并不会强制执行 Rust 的规则，因此 Rust 无法对这些代码进行检查，最终还是要靠开发者自己来保证代码的正确性和程序的安全性。
+
+#### ABI
+在 `exetrn "C"` 代码块中，我们列出了想要调用的外部函数的签名。其中 `"C"` 定义了外部函数所使用的**应用二进制接口**`ABI` (application binary interface)：`ABI` 定义了如何在汇编层面来调用该函数。在所有 `ABI` 中，C 语言的是最常见的。
+
+#### 在其它语言中调用 Rust 函数
+在 Rust 中调用其它语言的函数是让 Rust 利用其他语言的生态，那反过来可以吗？其他语言可以利用 Rust 的生态不？答案是肯定的。
+
+我们可以使用 `extern` 来创建一个接口，其它语言可以通过该接口来调用相关的 Rust 函数。但是此处的语法与之前有所不同，之前用的是语句块，而这里是在函数定义时加上 `extern` 关键字，当然，别忘了指定相应的 `ABI`：
+```rust
+#[no_mangle]
+pub extern "C" fn call_from_c() {
+    println!("Just called a Rust function from C!");
+}
+```
+
+上面的代码可以让 `call_from_c` 函数被 `C` 语言的代码调用，当然，前提是将其编译成一个共享库，然后链接到 C 语言中。
+
+这里还有一个比较奇怪的注解 `#[no_mangle]`，它用于告诉 Rust 编译器：不要乱改函数的名称。Mangling的定义是：当Rust 因为编译需要去修改函数的名称，例如为了让名称包含更多的信息，这样其它的编译部分就能从该名称获取相应的信息，这种修改会导致函数名变得相当不可读。
+
+因此，为了让 Rust 函数能顺利被其它语言调用，我们必须要禁止掉该功能。
+
+
+## 访问或修改一个可变的静态变量
+这部分我们在之前的[全局变量章节](https://course.rs/advance/global-variable.html#静态变量)中有过详细介绍，这里就不再赘述，大家可以前往此章节阅读。
+
+## 实现 unsafe 特征
+说实话，`unsafe` 的特征确实不多见，如果大家还记得的话，我们在之前的 [Send 和 Sync](https://course.rs/advance/concurrency-with-threads/send-sync.html#为原生指针实现sync) 章节中实现过 `unsafe` 特征 `Send`。
+
+之所以会有 `unsafe` 的特征，是因为该特征至少有一个方法包含有编译器无法验证的内容。`unsafe` 特征的声明很简单：
+```rust
+unsafe trait Foo {
+    // 方法列表
+}
+
+unsafe impl Foo for i32 {
+    // 实现相应的方法
+}
+
+fn main() {}
+```
+
+通过 `unsafe impl` 的使用，我们告诉编译器：相应的正确性由我们自己来保证。
+
+再回到刚提到的 `Send` 特征，若我们的类型中的所有字段都实现了 `Send` 特征，那该类型也会自动实现 `Send`。但是如果我们想要为某个类型手动实现 `Send` ，例如为原生指针，那么就必须使用 `unsafe`，相关的代码在之前的链接中也有，大家可以移步查看。
+
+总之，`Send` 特征标记为 `unsafe` 是因为 Rust 无法验证我们的类型是否能在线程间安全的传递，因此就需要通过 `unsafe` 来告诉编译器，它无需操心，剩下的交给我们自己来处理。
+
+
+## 访问 union 中的字段
+截止目前，我们还没有介绍过 `union` ，原因很简单，它主要用于跟 `C` 代码进行交互。
+
+访问 `union` 的字段是不安全的，因为 Rust 无法保证当前存储在 `union` 实例中的数据类型。
+
+```rust
+#[repr(C)]
+union MyUnion {
+    f1: u32,
+    f2: f32,
+}
+```
+
+上从可以看出，`union` 的使用方式跟结构体确实很相似，但是前者的所有字段都共享同一个存储空间，意味着往 `union` 的某个字段写入值，会导致其它字段的值会被覆盖。
+
+关于 `union` 的更多信息，可以在[这里查看](https://doc.rust-lang.org/reference/items/unions.html)。
+
+
+## 总结
+至此，`unsafe` 的五种兵器已介绍完毕，大家是否意犹未尽？我想说的是，就算意犹未尽，也没有其它武器了。
+
+就像上一章中所提到的，`unsafe` 只应该用于这五种场景，其它场景，你应该坚决的使用安全的代码，否则就会像 `actix-web` 的前作者一样，被很多人议论，甚至被喷。。。
+
+总之，能不使用 `unsafe` 一定不要使用，就算使用也要控制好边界，让范围尽可能的小，就像本章的例子一样，只有真的需要 `unsafe` 的代码，才应该包含其中, 而不是将无关代码也纳入进来。