add unsafe简介

book/contents/advance/unsafe/intro.md

@@ -1 +1,77 @@
-# unsafe
+# 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 ，是真心难查！