4.9 Unsafe Rust

unsafe 简介

虽然在本章之前，我们学到的代码都是在编译期就得到了 Rust 的安全保障，但是在其内心深处也隐藏了一些阴暗面，在这些阴暗面里，内存安全就存在一些变数了：当不娴熟的开发者接触到这些阴暗面，就可能写出不安全的代码，因此我们称这种代码为 unsafe 代码块。

1. 为何会有 unsafe

几乎每个语言都有 unsafe 关键字，但 Rust 语言使用 unsafe 的原因可能与其它编程语言还有所不同。

1.1 过强的编译器

说来尴尬，unsafe 的存在主要是因为 Rust 的静态检查太强了，但是强就算了，它还很保守，这就会导致当编译器在分析代码时，一些正确代码会因为编译器无法分析出它的所有正确性，结果将这段代码拒绝，导致编译错误。

这种保守的选择确实也没有错，毕竟安全就是要防微杜渐，但是对于使用者来说，就不是那么愉快的事了，特别是当配合 Rust 的所有权系统一起使用时，有个别问题是真的棘手和难以解决。

举个例子，在之前的自引用章节中，我们就提到了相关的编译检查是很难绕过的，如果想要绕过，最常用的方法之一就是使用 unsafe 和 Pin。

好在，当遇到这些情况时，我们可以使用 unsafe 来解决。此时，你需要替代编译器的部分职责对 unsafe 代码的正确性负责，例如在正常代码中不可能遇到的空指针解引用问题在 unsafe 中就可能会遇到，我们需要自己来处理好这些类似的问题。

1.2 特定任务的需要

至于 unsafe 存在的另一个原因就是：它必须要存在。原因是计算机底层的一些硬件就是不安全的，如果 Rust 只允许你做安全的操作，那一些任务就无法完成，换句话说，我们还怎么跟 C++ 干架？

Rust 的一个主要定位就是系统编程，众所周知，系统编程就是底层编程，往往需要直接跟操作系统打交道，甚至于去实现一个操作系统。而为了实现底层系统编程，unsafe 就是必不可少的。

在了解了为何会有 unsafe 后，我们再来看看，除了这些必要性，unsafe 还能给我们带来哪些超能力。

2. unsafe 的超能力

使用 unsafe 非常简单，只需要将对应的代码块标记下即可:

fn main() {
    let mut num = 5;

    let r1 = &num as *const i32;

    unsafe {
        println!("r1 is: {}", *r1);
    }
}

上面代码中, r1 是一个裸指针(raw pointer)，由于它具有破坏 Rust 内存安全的潜力，因此只能在 unsafe 代码块中使用，如果你去掉 unsafe {}，编译器会立刻报错。

言归正传， unsafe 能赋予我们 5 种超能力，这些能力在安全的 Rust 代码中是无法获取的：

• 解引用裸指针，就如上例所示
• 调用一个 unsafe 或外部的函数
• 访问或修改一个可变的静态变量
• 实现一个 unsafe 特征
• 访问 union 中的字段

在本章中，我们将着重讲解裸指针和 FFI 的使用。

3. unsafe 的安全保证

曾经在 reddit 上有一个讨论还挺热闹的，是关于 unsafe 的命名是否合适，总之公有公理，婆有婆理，但有一点是不可否认的：虽然名称自带不安全，但是 Rust 依然提供了强大的安全支撑。

首先，unsafe 并不能绕过 Rust 的借用检查，也不能关闭任何 Rust 的安全检查规则，例如当你在 unsafe 中使用引用时，该有的检查一样都不会少。

因此 unsafe 能给大家提供的也仅仅是之前的 5 种超能力，在使用这 5 种能力时，编译器才不会进行内存安全方面的检查，最典型的就是使用裸指针(引用和裸指针有很大的区别)。

4. 控制 unsafe 的使用边界

unsafe 不安全，但是该用的时候就要用，在一些时候，它能帮助我们大幅降低代码实现的成本。

而作为使用者，你的水平决定了 unsafe 到底有多不安全，因此你需要在 unsafe 中小心谨慎地去访问内存。

即使做到小心谨慎，依然会有出错的可能性，但是 unsafe 语句块决定了：就算内存访问出错了，你也能立刻意识到，错误是在 unsafe 代码块中，而不花大量时间像无头苍蝇一样去寻找问题所在。

正因为此，写代码时要尽量控制好 unsafe 的边界大小，越小的 unsafe 越会让我们在未来感谢自己当初的选择。

除了控制边界大小，另一个很常用的方式就是在 unsafe 代码块外包裹一层 safe 的 API，例如一个函数声明为 safe 的，然后在其内部有一块儿是 unsafe 代码。