|
|
# unsafe 简介
|
|
|
圣人论迹不论心，论心世上无圣人，对于编程语言而言，亦是如此。
|
|
|
|
|
|
虽然在本章之前，我们学到的代码都是在编译期就得到了 Rust 的安全保障，但是在其内心深处也隐藏了一些阴暗面，在这些阴暗面里，内存安全就存在一些变数了：当不娴熟的开发者接触到这些阴暗面，就可能写出不安全的代码，因此我们称这种代码为 `unsafe` 代码块。
|
|
|
|
|
|
## 为何会有 unsafe
|
|
|
几乎每个语言都有 `unsafe` 关键字，但 Rust 语言使用 `unsafe` 的原因可能与其它编程语言还有所不同。
|
|
|
|
|
|
#### 过强的编译器
|
|
|
说来尴尬，`unsafe` 的存在主要是因为 Rust 的静态检查太强了，但是强就算了，它还很保守，这就会导致当编译器在分析代码时，一些正确代码会因为编译器无法分析出它的所有正确性，结果将这段代码拒绝，导致编译错误。
|
|
|
|
|
|
这种保守的选择确实也没有错，毕竟安全就是要防微杜渐，但是对于使用者来说，就不是那么愉快的事了，特别是当配合 Rust 的所有权系统一起使用时，有个别问题是真的棘手和难以解决。
|
|
|
|
|
|
举个例子，在之前的自引用章节中，我们就提到了相关的编译检查是很难绕过的，如果想要绕过，最常用的方法之一就是使用 [`unsafe` 和 `Pin`](https://course.rs/advance/circle-self-ref/self-referential.html)。
|
|
|
|
|
|
好在，当遇到这些情况时，我们可以使用 `unsafe` 来解决。此时，你需要替代编译器的部分职责对 `unsafe` 代码的正确性负责，例如在正常代码中不可能遇到的空指针解引用问题在 `unsafe` 中就可能会遇到，我们需要自己来处理好这些类似的问题。
|
|
|
|
|
|
|
|
|
#### 特定任务的需要
|
|
|
至于 `unsafe` 存在的另一个原因就是：它必须要存在。原因是计算机底层的一些硬件就是不安全的，如果 Rust 只允许你做安全的操作，那一些任务就无法完成，换句话说，我们还怎么跟 C++ 干架？
|
|
|
|
|
|
Rust 的一个主要定位就是系统编程，众所周知，系统编程就是底层编程，往往需要直接跟操作系统打交道，甚至于去实现一个操作系统。而为了实现底层系统编程，`unsafe` 就是必不可少的。
|
|
|
|
|
|
在了解了为何会有 `unsafe` 后，我们再来看看，除了这些必要性，`unsafe` 还能给我们带来哪些超能力。
|
|
|
|
|
|
## unsafe 的超能力
|
|
|
使用 `unsafe` 非常简单，只需要将对应的代码块标记下即可:
|
|
|
```rust
|
|
|
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` 或外部的函数
|
|
|
- 访问或修改一个可变的[静态变量](https://course.rs/advance/global-variable.html#静态变量)
|
|
|
- 实现一个 `unsafe` 特征
|
|
|
- 访问 `union` 中的字段
|
|
|
|
|
|
在本章中，我们将着重讲解原生指针和 FFI 的使用。
|
|
|
|
|
|
## unsafe 的安全保证
|
|
|
曾经在 `reddit` 上有一个讨论还挺热闹的，是关于 `unsafe` 的命名是否合适，总之公有公理，婆有婆理，但有一点是不可否认的：虽然名称自带不安全，但是 Rust 依然提供了强大的安全支撑。
|
|
|
|
|
|
首先，`unsafe` 并不能绕过 Rust 的借用检查，也不能关闭任何 Rust 的安全检查规则，例如当你在 `unsafe` 中使用**引用**时，该有的检查一样都不会少。
|
|
|
|
|
|
因此 `unsafe` 能给大家提供的也仅仅是之前的 5 种超能力，在使用这5种能力时，编译器才不会进行内存安全方面的检查，最典型的就是使用**原生指针**(引用和原生指针有很大的区别)。
|
|
|
|
|
|
## 谈虎色变？
|
|
|
在网上充斥着这样的言论：`千万不要使用 unsafe，因为它不安全`，甚至有些库会以没有 `unsafe` 代码作为噱头来吸引用户。事实上，大可不必，如果按照这个标准，Rust 的标准库也将不复存在！
|
|
|
|
|
|
Rust 中的 `unsafe` 其实没有那么可怕，虽然听上去很不安全，但是实际上 Rust 依然提供了很多机制来帮我们提升了安全性，因此不必像对待 Go 语言的 `unsafe` 那样去畏惧于使用Rust中的 `unsafe` 。
|
|
|
|
|
|
大致使用原则总结如下：没必要用时，就不要用，当有必要用时，就大胆用，但是尽量控制好边界，让 `unsafe` 的范围尽可能小。
|
|
|
|
|
|
## 控制 unsafe 的使用边界
|
|
|
`unsafe` 不安全，但是该用的时候就要用，在一些时候，它能帮助我们大幅降低代码实现的成本。
|
|
|
|
|
|
而作为使用者，你的水平决定了 `unsafe` 到底有多不安全，因此你需要在 `unsafe` 中小心谨慎地去访问内存。
|
|
|
|
|
|
即使做到小心谨慎，依然会有出错的可能性，但是 `unsafe` 语句块决定了：就算内存访问出错了，你也能立刻意识到，错误是在 `unsafe` 代码块中，而不花大量时间像无头苍蝇一样去寻找问题所在。
|
|
|
|
|
|
正因为此，写代码时要尽量控制好 `unsafe` 的边界大小，越小的 `unsafe` 越会让我们在未来感谢自己当初的选择。
|
|
|
|
|
|
除了控制边界大小，另一个很常用的方式就是在 `unsafe` 代码块外包裹一层 `safe` 的 API，例如一个函数声明为 safe 的，然后在其内部有一块儿是 `unsafe` 代码。
|
|
|
|
|
|
> 忍不住抱怨一句，内存安全方面的 bug ，是真心难查！
|
