現代 C++ 救不了程序員

常常有程序員爲C++辯護說：「只要你不使用任何從C繼承過來的功能，C++就是安全的」！但事實非如此。

根據本文做者在大型C++項目上（聽從現代的慣用作法）的經驗來看，C++提供的類型徹底不能阻止漏洞的泛濫。本文中就會給出一些徹底根據現代C++的慣用作法編寫的代碼，你會發現這些代碼仍然會引起漏洞。

如下爲譯文：

我常常批評內存不安全的語言，主要是C和C++，以及它們引起的大量安全漏洞。根據大量使用C和C++的軟件項目的審查結果，我得出了一個結論：軟件行業應該使用內存安全的語言（例如Rust和Swift）。

人們經常在回覆我時說，這個問題並非C和C++自己的問題，而是使用這兩種語言的開發者的錯。

具體來講，我常常聽到人們爲C++辯護說：「只要你不使用任何從C繼承過來的功能，C++就是安全的」（我理解這句話指的是原始指針、數組做爲指針使用、手動malloc/free以及其餘相似功能。但我認爲有一點值得注意，因爲C的特性明確地融入了C++，那麼在實踐中，大部分C++代碼都須要處理相似的狀況。），或者相似的話，好比只要聽從現代C++的類型和慣用作法，就不會引起內存方面的漏洞。

我很感謝C++的智能指針類型，由於這種類型的確很是有用。不幸的是，根據我在大型C++項目上（聽從現代的慣用作法）的經驗來看，光靠這些類型徹底不能阻止漏洞的泛濫。我會在本文中給出一些徹底根據現代C++的慣用作法編寫的代碼，你會發現這些代碼仍然會引起漏洞。

掩蓋「釋放後使用」的引用

我想說的第一個例子最初是Kostya Serebryany提出的（github.com/isocpp/CppC…

#include <iostream>
#include <string>
#include <string_view>

int main() {
  std::string s = "Hellooooooooooooooo ";
  std::string_view sv = s + "World\n";
  std::cout << sv;
}

複製代碼

在這段代碼中，s + "World\n"分配了一個新的std::string，而後將其轉換成std::string_view。此時臨時的std::string被釋放，但sv依然指向它原來擁有的內存。任何對sv的訪問都會形成「釋放後使用」的漏洞。

天啊！C++的編譯器沒法檢測到sv擁有某個引用，而該引用的壽命比被引用的對象還要長的狀況。一樣的問題也會影響std::span，它也是個很是現代的C++類型。

另外一個有意思的例子是使用C++的lambda功能來掩蓋引用：

#include <memory>
#include <iostream>
#include <functional>


std::function<int(void)> f(std::shared_ptr<int> x) {
    return [&]() { return *x; };
}

int main() {
    std::function<int(void)> y(nullptr);
    {
        std::shared_ptr<int> x(std::make_shared<int>(4));
        y = f(x);
    }
    std::cout << y() << std::endl;
}
複製代碼

上述代碼中，f中的[&]代表lambda用引用的方式來捕獲值。而後在main中，x超出了做用域，從而銷燬了指向數據的最後一個引用，致使數據被釋放。此時y就成了懸空指針。即便咱們謹慎地使用智能指針也沒法避免這個問題。沒錯，人們的確會編寫代碼來處理std::shared_ptr&，做用之一就是設法避免引用計數無謂的增長或減小。

std::optional解引用

std::optional表示一個可能存在也可能不存在的值，一般用來替換哨兵值（如-1或nullptr）。它提供的一些方法，如value()，可以提取出它包含的T，並在optional爲空的時候拋出異常。可是，它也定義了operator*和operator->。

這兩個方法能訪問底層的T，但它們並不會檢查optional是否包含值。

例如，下面的代碼就會返回未初始化的值：

#include <optional>

int f() {
    std::optional<int> x(std::nullopt);
    return *x;
}
複製代碼

若是用std::optional來代替nullptr，就會產生更加嚴重的問題！對nullptr進行解引用會產生段錯誤（這並非安全漏洞，只要不是在舊的內核上）。而對nullopt進行解引用會產生未初始化的值做爲指針，這會致使嚴重的安全問題。儘管T*也可能擁有未經初始化的值，可是這種狀況很是罕見，遠遠不如對正確地初始化成nullptr的指針進行解引用的操做。

並且，這個問題並不須要使用原始的指針。即便使用智能指針也能獲得未初始化的野指針：

#include <optional>
#include <memory>

std::unique_ptr<int> f() {
    std::optional<std::unique_ptr<int>> x(std::nullopt);
    return std::move(*x);
}
複製代碼

std::span索引

std::span能讓咱們方便地傳遞指向一片連續內存的引用以及長度值。這樣針對多種不一樣類型進行編程就很容易：std::span<uint8_t>能夠指向std::vector<uint8_t>、std::array<uint8_t, N>擁有的內存，甚至能夠指向原始指針擁有的內存。不檢查邊界就會致使安全漏洞，而許多狀況下，span能幫你確保長度是正確的。

與其餘STL數據結構同樣，span的operator[]方法並不會進行任何邊界檢查。這是能夠理解的，由於operator[]是最經常使用的方法，也是訪問數據結構的默認方法。而至少從理論上，std::vector和std::array能夠安全地使用，由於它們提供了at()方法，該方法會進行邊界檢查（在實踐中我歷來沒見人用過這個方法，不過能夠想象一個項目，經過靜態分析工具來禁止調用std::vector::operator[]）。span不提供at()方法，也不提供任何進行邊界檢查的方法。

有趣的是，Firefox和Chromium移植的std::span都會在operator[]中進行邊界檢查，因此這兩個項目也沒法安全地移植到std::span上。

結論

現代C++的慣用作法帶來了許多改變，可以改善安全性：智能指針能更好地表示預想的生命週期，std::span能保證永遠有正確的長度，std::variant爲union提供了安全的抽象。可是，現代C++也引入了一些新的漏洞禍根：lambda捕獲致使的釋放後使用，未初始化的optional，以及沒有邊界檢查的span。

以我編寫比較現代的C++的經驗，以及審查Rust代碼（包括使用了大量unsafe的Rust代碼）的經驗來看，現代C++的安全性徹底比不上那些保證內存安全的語言，如Rust、Swift（或者Python和JavaScript，儘管我不多見到可以合理地用Python或C++編寫的程序）。

不能否認，將現有的C和C++代碼移植到其餘語言依然是個難題。但不管如何，問題應該是咱們應該怎樣作，而不是咱們是否應該作。事實證實，即便最現代的C++慣用作法，也不可能保證C++的正確性。