C++發(fā)布革命性提案：“借鑒”Rust精華，內(nèi)存安全即將成為標配？

C語言與CPP編程

點擊上方“C語言與CPP編程”，選擇“關(guān)注/置頂/星標公眾號”干貨福利，第一時間送達！最近有小伙伴說沒有收到當天的文章推送，這是因為微信改了推送機制，確實會一部分有小伙伴刷不到當天的文章，一些比較實用的知識和信息，錯過了就是錯過了。所以建議大家加個星標??，就能第一時間收到推送了。

編譯 | 核子可樂、Tina    轉(zhuǎn)自 | InfoQ
                想要內(nèi)存安全？那就給你們內(nèi)存安全！我們也有自己的借用檢查器。        在被“內(nèi)存安全”議題反復折磨了兩年之后，C++ 社區(qū)已經(jīng)發(fā)布一項提案，旨在幫助開發(fā)人員減少代碼中的安全漏洞。
這項 Safe C++ Extension 安全擴展提案希望解決這種編程語言中的致命弱點，保證其就此告別內(nèi)存安全漏洞。
C++ 聯(lián)盟總裁兼執(zhí)行董事 Vinnie Falco 上周四表示，“這是一項革命性的提案，將為 C++ 編程語言帶來內(nèi)存安全功能。這次合作也標志著 C++ 生態(tài)系統(tǒng)的一個重要里程碑，相信大家也感受到行業(yè)對于安全代碼的需求從未如此迫切�！�


                1 內(nèi)存安全的需求確實從未如此迫切        在過去兩年之間，各類私營和公共部門組織一直在敦促和推動程序員們使用內(nèi)存安全語言（例如 C#、Go、Java、Python 以及 Swift）編寫新應(yīng)用程序，同時重寫舊有應(yīng)用程序。其中最典型的選項當數(shù) Rust，一款性能良好的低級系統(tǒng)語言。
軟件工程師 Alex Gaynor 早在 2019 年就提出了這個問題，他表示大型代碼庫中的大多數(shù)嚴重漏洞都來自內(nèi)存安全缺陷，例如緩沖區(qū)溢出與釋放后使用。他強調(diào)稱，“數(shù)據(jù)已經(jīng)一再證明，當項目使用內(nèi)存不安全語言（例如 C 和 C++）時，就會受到大量由此產(chǎn)生的安全漏洞的困擾�！�
在此之后，內(nèi)存安全迅速成為學術(shù)論文和技術(shù)會議中常見的討論主題。2022 年 9 月，微軟 Azure 首席技術(shù)官 Mark Russinovich 也下場靜態(tài)，呼吁開發(fā)人員棄用 C 和 C++，轉(zhuǎn)投 Rust 的懷抱。
幾個月后，美國國安局也采取了類似的立場。到 2023 年，內(nèi)存安全已然成為主流話題，Consumer Reports 消費者報告也對此進行了報道。
面對 Rust 的浩大攻勢，C++ 陣營這邊則警惕地組織起防守陣形。兩年之前，在回應(yīng) Russinovich 對于棄用 C/C++ 的呼吁時，C++ 語言的締造者 Bjarne Stroustrup 就在采訪中坦言，“我們現(xiàn)在可以在 ISO C++ 中實現(xiàn)完美的類型與內(nèi)存安全保障。”
然而這個說法遭到了一些質(zhì)疑�；ヂ�(lián)網(wǎng)安全研究小組（ISRG）的聯(lián)合創(chuàng)始人兼執(zhí)行董事 Josh Aas 就負責監(jiān)督一項名為 Prossimo 的內(nèi)存安全計劃，他去年曾在采訪中證實，盡管理論上確實可以編寫內(nèi)存安全的 C++ 代碼，但其在現(xiàn)實中其實無法實現(xiàn)，因為 C++ 并沒有在立項之初就考慮到內(nèi)存安全設(shè)計。
安全 C++ 擴展提案就是為了解決這些批評而生，同時也響應(yīng)了美國國安局、其他五眼國家情報機構(gòu)、美國網(wǎng)絡(luò)安全與基礎(chǔ)設(shè)施安全局（CISA）白宮以及國防高級研究計劃局（DARPA）對于各公共部門提出的內(nèi)存安全要求。
今年 8 月，Gaynor 重新討論了內(nèi)存安全問題，并指出雖然嘗試讓 C++ 更安全確有現(xiàn)實意義，但他仍對這種意義的具體程度表示懷疑�！拔业膽B(tài)度很明確，C++ 的安全性可以得到實質(zhì)性改進。更具體地講，完全解決內(nèi)存安全問題似乎也不是不可能。但相信大家也跟我一樣有著同樣的共識，那就是對于讓 C++ 在安全性方面比肩 Swift、Go 或者 Rust 這個問題上，恐怕并不存在一個簡單易行的解決方案�！�
盡管如此，安全 C++ 擴展提案仍想要一試身手。C++ 聯(lián)盟開發(fā)人員 Sean Gaxter（Circle 編譯器的創(chuàng)造者）與 Christian Mazakas 承認，目前行業(yè)對于采用內(nèi)存安全編程語言的呼聲可謂震耳欲聾。在他們看來，雖然 Rust 只是一種流行的系統(tǒng)級編程語言、沒有垃圾收集功能、可以提供嚴格的內(nèi)存安全保障，但將 C++ 代碼遷移至 Rust 還是會帶來很多問題。
                2 將大量 Rust 內(nèi)容復制到了 C++ 中？       

https://safecpp.org/draft.html
他們在提案中解釋道，“Rust 缺少函數(shù)重載、模板、繼承和異常機制，C++ 則缺少特征、重新定位與借用檢查。這些差異也導致這兩種語言在對接時產(chǎn)生種種不匹配狀況。大多數(shù)用于跨語言綁定的代碼生成器，根本就無法用某一種語言的特性來表達另一種語言的特性。”
盡管 DARPA 正在嘗試開發(fā)出更好的 C++ 到 Rust 自動化轉(zhuǎn)換工具，但 Baxter 和 Mazakas 認為，強迫資深 C++ 程序員們學習 Rust 并不是理想的答案——不久之前，一位專注于 C 語言的 Linux 內(nèi)核維護者甚至因此辭去了工作。
他們爭辯道，“Rust 對于職業(yè) C++ 開發(fā)者來說差異性過大，再加上互操作工具不夠便利，就導致通過用 Rust 重寫關(guān)鍵部分以強化 C++ 應(yīng)用程序變得極其困難。所以，為什么沒有針對內(nèi)存安全的語言解決方案？為什么就沒有安全版的 C++？”
Baxter 還在采訪中提到，盡管過去幾十年來，無數(shù)計算機科學家一直在關(guān)注如何對程序的正確性做出證明，但現(xiàn)如今這個問題已經(jīng)上升到了核心國家安全的高度。
Baxter 解釋稱，“近期政府對于內(nèi)存安全問題的警告，促使整個科技行業(yè)都在關(guān)注這個問題。我研究了這一理論，并從中發(fā)現(xiàn)了新機會：設(shè)計新工具，幫助 C++ 工程師們編寫出質(zhì)量更高的程序，同時消除與安全漏洞相關(guān)的各類軟件缺陷。”
Baxter 還指出，安全 C++ 項目引入了保障內(nèi)存安全的新技術(shù)，而不僅僅是對原有最佳實踐的重申�！鞍踩� C++ 能夠防止用戶編寫出不健全的代碼，同時輔以編譯時智能，例如通過借用檢查來防止使用后釋放錯誤、初始化分析以確保類型安全等�！�
Baxter 表示，用不同編程語言重寫項目的成本很高，所以安全 C++ 的目標是以更低的成本實現(xiàn)與 Rust 相同的健全性保證，進而降低內(nèi)存安全的準入門檻。他解釋道，“有了安全 C++，現(xiàn)有代碼能夠像以往一樣繼續(xù)正常運行，而各利益相關(guān)方則可以更好地把控程序安全�！�
至于下一步，還需要科技行業(yè)的更多參與，以幫助實現(xiàn)安全 C++ 提出的項目目標。
他總結(jié)道，“基礎(chǔ)已經(jīng)打好：我們有了出色的借用檢查和初始化分析機制，這也是健全性保障的實現(xiàn)基礎(chǔ)。下一步是全面對接 C++ 的所有功能特性，并為其指定內(nèi)存安全版本。這是一項艱巨的工作，但考慮到減少 C++ 安全漏洞的重大意義，這份付出絕對物有所值�！�
社區(qū)對此提案褒貶不一。
有人提到，“這個話題如此重要，令人難以置信的是它還沒有進入主流新聞”。他還表示，經(jīng)過幾十年不安全和脆弱代碼的困擾，終于有了一個官方且實用的“智能感知”機制來確保代碼的正確性，不過遲到總比不到好。
另一位二十多年的資深 C++ 開發(fā) James20k 認為，“在 C++ 內(nèi)存安全的所有提案中，這個提案感覺是迄今為止最明智的。”
他認為該提案最大的優(yōu)點是基于實際的，且它是完全可選的，對現(xiàn)有的 C++ 不會發(fā)生任何變化。而且已被證明是可實現(xiàn)的，不像其他替代方案。Carbon、cpp2、clang-lifetimes、profiles 等要么內(nèi)存不安全，要么無法完全實現(xiàn)，要么就是沒有用。另外，它提供了一個完全內(nèi)存安全的 C++ 版本，并且沒有損失表達能力。
但他指出這個提案的一個缺點就是“明確地基于 Rust”，“你已經(jīng)能看到這引發(fā)的強烈爭論了。遺憾的是，委員會對此類事情也并非免疫�！�
很明顯，社區(qū)中一部分技術(shù)人員對借鑒 Rust 中的內(nèi)容有些異議。

我希望他們不要加入借用檢查器，也不要把 C++ 變成某種奇怪的 Rust 混合體。我真的比 Rust 更喜歡 C++。我喜歡 C++ 帶來的自由，我認為這也是它的主要賣點之一。


我原本以為會看到一個關(guān)于 C++ 安全性的方案，但這個規(guī)范中大量借鑒了 Rust 的內(nèi)容，應(yīng)用在 C++ 上。正因為有這樣的預(yù)期差異，閱讀過程中有時覺得像是在看一場惡搞。就像，作者是不是在開玩笑，把 Rust 的內(nèi)容用 C++ 語法呈現(xiàn)，稱之為“安全 C++”？
不過，看起來這確實是一個經(jīng)過深思熟慮的提案，作者投入了大量精力。對作者們來說，干得不錯！現(xiàn)在談?wù)勎业膶嶋H想法：我個人認為，這個提案對語言的改變太大了，甚至比 C++11 的變動還要大。我真的很想問，這是唯一的方式嗎？或許這是目前唯一經(jīng)過驗證的方式。也許隨著更多人關(guān)注這個提案，有人可以在此基礎(chǔ)上進一步改進規(guī)范，如果這樣的改進是可能的話。

我并不反對在 C++ 中加入安全性改進的想法。但這個提案給我的感覺像是“試圖讓 C++ 變得像 Rust”。Rust 確實有一些很好的特性，但我們的目標應(yīng)該是以 C++ 自己的方式進行改進，而不是試圖成為另一種語言。
                3 Linus Torvalds 出言定性：Rust 帶來了新的“信仰之爭”        有開發(fā)者認為，C++ 要么朝這個方向發(fā)展，要么輸給 Rust 并消亡。
這種觀點反映了編程語言之間的競爭往往被過度情緒化，也是一種引戰(zhàn)的言論。C++ 和 Rust 都是工具，沒有誰需要“勝利”，但每次在 C++ 社區(qū)中提到 Rust，都會引發(fā)一場老式的口水戰(zhàn)。這種 C++ 和 Rust 之間的“文化戰(zhàn)”往往讓人想起 C 和 Rust 之間的爭論。
在 Linux 締造者 Linus Torvalds 看來，如今Rust 帶來的爭議，“幾乎上升到了帶有宗教戰(zhàn)爭色彩的信仰之爭層面”。

在 9 月 16 日最新開源峰會的主題演講當中，Torvalds 評論了 Linux 社區(qū)中 C 與 Rust 之爭。最近，微軟軟件工程師、Rust for Linux 維護者之一 Wedson Almeida 在給 Linux 內(nèi)核郵件列表 (LKML) 的一封信中表示自己已經(jīng)退出了該項目。在 Linux 內(nèi)核圈子里，一些開發(fā)人員和維護人員不想與 Rust 有任何關(guān)系，他們毫不避諱地表達了他們認為該編程語言已經(jīng)失敗的觀點。
對此，即使是不介意爭論的 Torvalds 也承認，“有些爭論很激烈。”
Torvalds 強調(diào)，“我其實并不反感爭論，畢竟真理越辯越明。我認為 Rust 的一大優(yōu)點，在于它能讓某些討論煥發(fā)生機，但也會讓不少爭論變得非常激烈……這至少表明很多人正深切關(guān)心這門語言�？闪硪环矫�，我也不太理解為什么 Rust 總會成為激起爭議的核心。這讓我想起年輕那會，人們關(guān)于 vi 和 emacs 的大戰(zhàn)。不過出于某種原因，感覺 Rust 和 C 的討論幾乎上升到了帶有宗教戰(zhàn)爭色彩的信仰之爭層面�！�
這場爭議可以追溯到三年之前，當時就有人提出“Rust 可以成為內(nèi)核項目的一部分甚至取代 C 語言”的觀點。此時一切還都很正常，可后續(xù)情況卻很快走向了失控的邊緣。例如，使用 C 語言可能在 CPU 上產(chǎn)生著名的緩沖區(qū)溢出漏洞，但目前這類情況已經(jīng)很少出現(xiàn)。雖然 Rust 能夠提供某些安全功能，但也有自己的弊端，畢竟與相對容易掌握的 C 語言相比，其學習曲線明顯更加陡峭。
正如 Torvalds 在演講中的解釋，C 是一種相對“容易掌握的語言”，這也是“我喜歡 C 的原因之一，更是很多 C 語言程序員喜歡它的原因之一——但同時也必須承認，正是因為它很簡單，所以很容易在使用時犯錯誤。而 Rust 則完全不同。有很多人已經(jīng)習慣了 C 的思考模式，所以不一定能接受這種差異，但這其實沒什么�！�
不過必須承認，C 和 Rust 兩派的分歧很大。Torvalds 進一步指出，“有些人就是不喜歡 Rust 提出的概念，也不喜歡 Rust 侵占自己的領(lǐng)域……不少人甚至斷言 Rust 的融合之路是失敗的。我之前就對此表達過反對——我們已經(jīng)在這方面探索了幾年，所以目前下結(jié)論還為時過早。但我也認為，哪怕是失敗了（雖然我并不支持這種失敗論），這也是學習經(jīng)歷的一部分。所以我覺得推廣 Rust 是有積極意義的，可爭論過程中的很多人似乎并不這么看�！�
Torvalds 表示，挑戰(zhàn)在于內(nèi)存安全架構(gòu)對于基礎(chǔ)設(shè)施做出了某些假設(shè)。
“基礎(chǔ)設(shè)施人員可能會對此感到害怕，但這已經(jīng)是個公開的秘密了。換言之，基礎(chǔ)設(shè)施人員似乎在抵制這些變化。公平地講，我們對 C 基礎(chǔ)設(shè)施也做了不少改變。內(nèi)核編碼其實在很大程度上也超出了常規(guī)的 C 語言范疇，我們不僅會以某種方式編寫代碼，同時也在 C 語言這邊部署了很多用于執(zhí)行語言之外基礎(chǔ)設(shè)施規(guī)則的工具方案。這就是我們對于安全性的探索和保障。我們在 C 語言這邊其實建設(shè)了大量內(nèi)存安全基礎(chǔ)設(shè)施，從技術(shù)上講它們并不屬于 C 的組成部分——而更多是我們內(nèi)核基礎(chǔ)設(shè)施的組成部分。我們擁有調(diào)試版本，能夠讓內(nèi)核運行得更慢，同時對更多內(nèi)存安全要素進行測試。”
很明顯，Rust 和 C 語言各擅勝場。Rust 支持者們拿出了大量有力的論據(jù)（只要能夠編譯通過，代碼質(zhì)量就有保障；而且泛用性更好等），而 C 語言派則認為這位老將更容易學習，而且在過去數(shù)十年的開發(fā)應(yīng)用中積累下了巨大的生態(tài)財富，更適用于以內(nèi)核為中心的 eBPF 開發(fā)。
正如思科 Isovalent 首席開源官 Liz Rice 在采訪中所言，Rust 更新，具有“非常強大的優(yōu)勢，但并不是每個人都能立即適應(yīng)并掌握 Rust 的開發(fā)思路。不少在內(nèi)核中開發(fā) eBPF 子系統(tǒng)的人們，絕不可能突然轉(zhuǎn)過身來選擇 Rust 來完成日常工作。其實很多人都在討論這個問題，比如說「如果我們能用 Rust 處理所有開發(fā)任務(wù)，那 eBPF 驗證器就可以直接刪掉了，根本不需要它�！沟�我認為持這種說法的朋友，其實沒有完全理解 eBPF 驗證器的全部作用。我們可以用 Rust 編寫 eBPF 代碼并將其編譯為 eBPF 字節(jié)碼，這才是想要編寫 eBPF 的 Rust 開發(fā)者所應(yīng)當選擇的路線。”
與此同時，Polar Signals 公司 CEO 兼創(chuàng)始人 Frederic Branczyk 也在采訪中強調(diào)，“Rust 中亦有不少實例證明，開發(fā)者必須先做一些非安全實踐，之后在此基礎(chǔ)上建立起安全的抽象。所以我絕不認為 Rust 會成為搞定一切的萬靈藥。順帶一提，我本身是 Rust 的忠實粉絲，可雖然 Rust 也能完成很多工作，但我還是認為 C 才是操作系統(tǒng)編寫方面的理想語言�！�
延伸閱讀：
C++ 之父 Bjarne Stroustrup：我會為全球數(shù)十億行 C++ 代碼帶來一個嶄新的解決方案
參考鏈接：
https://cppalliance.org/vinnie/2024/09/12/Safe-Cpp-Partnership.html
https://safecpp.org/P3390R0.html
https://www.youtube.com/watch?v=OM_8UOPFpqE&t=510s
https://www.theregister.com/2024/09/16/safe_c_plusplus/?td=rt-3a
https://www.youtube.com/watch?v=OM_8UOPFpqE&t=510s
https://thenewstack.io/linus-torvalds-c-vs-rust-debate-has-religious-undertones/
https://www.zdnet.com/article/linus-torvalds-muses-about-maintainer-gray-hairs-and-the-next-king-of-linux/
https://www.reddit.com/r/cpp/comments/1fiuhb7/the_empire_of_c_strikes_back_with_safe_c_proposal/
你好，我是飛宇。日常分享C/C++、計算機學習經(jīng)驗、工作體會，歡迎點擊此處查看我以前的學習筆記&經(jīng)驗&分享的資源。
我組建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起進群交流。

歡迎你添加我的微信，我拉你進技術(shù)交流群。此外，我也會經(jīng)常在微信上分享一些計算機學習經(jīng)驗以及工作體驗，還有一些內(nèi)推機會。


加個微信，打開另一扇窗
經(jīng)常遇到有讀者后臺私信想要一些編程學習資源，這里分享 1T 的編程電子書、C/C++開發(fā)手冊、Github上182K+的架構(gòu)路線圖、LeetCode算法刷題筆記等精品學習資料，點擊下方公眾號會回復"編程"即可免費領(lǐng)取~

感謝你的分享，點贊，在看三連