從未定義到有定義：std::launder 到底何時該用
Standard C++ Blog · 2026-07-02
背景
C++ 專家 Andreas Fertig 於 2026 年 7 月 2 日在 Standard C++ 官方部落格重新整理了 std::launder 的使用時機，原文出自他個人部落格較早的技術筆記。問題核心是編譯器對指標所指物件的「快取假設」會在 placement new 之後失效卻沒被察覺。文章用一個帶 const 成員的類別示範這個陷阱：
struct X {
const int n;
double d;
};
X* p = new X{7, 8.8};
new(p) X{42, 9.9}; // placement new
int i = p->n; // 未定義行為
auto d = p->d; // 未定義行為
由於 n 是 const，編譯器有權假設它在建構後永不改變，即使程式用 placement new 在原地重建了整個物件並寫入新值 42，透過舊指標 p 讀取 n 仍然是未定義行為。這不是實作缺陷，而是 C++ 物件模型允許的合法優化，只是結果違反直覺。
規格細節
C++17 由 P0532R0 引入 std::launder，作用是「更新一個已經存在生命週期物件的指標視圖」。它本質上是一道優化屏障，告訴編譯器不要沿用舊指標的既有假設，而是把它當成指向新物件的全新指標重新分析。常見寫法出現在自訂記憶體配置器裡：
template<typename T>
[[nodiscard]] T* Get() {
return std::launder(reinterpret_cast<T*>(mBuffer));
}
文章也釐清了 std::launder 與其他工具的分工：reinterpret_cast 只轉換指標型別，不處理生命週期問題；std::bit_cast（C++20）用於取得位元表示；C++23 新增的 std::start_lifetime_as 則是直接在記憶體中「啟動」一個物件的生命週期，很多時候比 std::launder 更貼近需求、也更不容易誤用。
影響範圍
會踩到這個問題的多半是撰寫底層基礎設施的工程師：自訂配置器、序列化框架、嵌入式韌體裡大量使用 placement new 重建物件的場景最為常見。文章提醒，Get() 這類函式仍隱含一個前提——呼叫端必須保證緩衝區裡已經有合法建構的物件，std::launder 本身不會檢查這件事。對於能上 C++23 的專案，作者建議優先評估 std::start_lifetime_as 作為更直接的替代方案，只有在維護舊標準相容性時才需要死記 std::launder 的適用邊界。
兩份記憶體管理修補集，兩種用 LLM 的方式
LWN.net · 2026-07-02
背景
Linux 核心社群對 AI 輔助開發的規範化始於 2026 年 4 月併入的 AI Coding Assistants 政策文件：任何用到 AI 工具產生的修補，都必須加上 Assisted-by 標籤註明模型與輔助工具，例如 Assisted-by: Claude:claude-3-opus coccinelle sparse，且只有人類可以簽署 DCO。這份政策把「揭露」和「究責」分開處理：AI 可以協助寫程式碼，但送出修補、審查、測試與授權合規的責任全部落在人類開發者身上。與此同時，記憶體管理（mm）子系統維護者 Andrew Morton 也一度提議要求開發者必須回應 LLM 審查工具 Sashiko 的所有意見，但子維護者 Lorenzo Stoakes 以誤判率過高為由反對強制執行，目前 Sashiko 在 mm 子系統仍維持選用性質。
兩種做法的對比
LWN 這篇文章記錄了同一時期出現的兩個記憶體管理修補集，呈現出使用 LLM 的兩種極端。其中一位開發者把未經整理的 AI 生成內容直接寄到郵件論壇，被讀者在文章留言區形容為「不該做的事」——把 AI 對話直接丟給社群，等於把消化理解的工作丟給收信的人。留言者建議，若只是要徵求設計意見，更恰當的做法是先寫一份經過整理的 RFC，AI 可以輔助起草，但送出前仍要尊重讀者。
另一位開發者則採取相反策略：把 LLM 當成一起工作的夥伴，而不是一台輸入需求就吐出程式碼的機器。這種做法透過緊湊的回饋迴圈持續驗證輸出、在過程中持續建立自己對程式碼的理解，最終修補集的接受度明顯更好。這個對比恰好呼應了 Sashiko 審查機制設計初衷——工具能找出人類容易忽略的資源管理問題，但前提是使用者願意花時間理解回饋，而非只求「能動就好」。
影響範圍
這場對比發生的同一週，Assisted-by 標籤本身也再度成為爭論焦點。核心開發者 Christian Brauner 在郵件論壇發起討論，質疑目前標籤要求註明模型版本與工具細節的做法，等於讓 git 歷史變成「AI 公司的免費廣告牌」，主張至少簡化成只寫工具名稱；另一位開發者 Jeff Layton 則直接提交修補，主張整套 Assisted-by 要求訊噪比太低、乾脆從核心文件中移除。兩份修補集的對比與標籤存廢之爭同時發生，反映出核心社群仍未就「如何揭露 AI 使用」達成共識，Linus Torvalds 截至目前尚未在任一討論串表態。
原始來源：LWN.net、Linux Kernel AI Coding Assistants 政策文件、Phoronix 報導
Secure Boot 憑證到期潮正式開始
LWN.net · 2026-07-01
背景
UEFI Secure Boot 的信任鏈由平台金鑰（PK）開始，往下授權 KEK（Key Enrollment Key），再由 KEK 授權簽署 db（允許清單）與 dbx（撤銷清單）的更新。微軟在 2011 年簽發的一批憑證從 2026 年 6 月開始陸續到期：Microsoft Corporation KEK CA 2011 於 6 月 24 日到期，兩份 Microsoft UEFI CA 2011（分別用於簽第三方開機載入器與 Option ROM）於 6 月 27 日到期，Microsoft Windows Production PCA 2011（簽 Windows 開機管理員）則在 10 月 19 日到期。微軟自 2025 年 10 月起已用新舊兩把金鑰雙簽，2026 年 6 月之後新簽署只會使用新一代憑證。
| 到期憑證 | 到期日 | 接替憑證 | 用途 |
|---|---|---|---|
KEK CA 2011 | 2026-06-24 | KEK 2K CA 2023 | 簽署 db/dbx 更新 |
UEFI CA 2011 | 2026-06-27 | UEFI CA 2023 | 簽第三方開機載入器 |
UEFI CA 2011（Option ROM） | 2026-06-27 | Option ROM UEFI CA 2023 | 簽第三方 Option ROM |
Windows Production PCA 2011 | 2026-10-19 | Windows UEFI CA 2023 | 簽 Windows 開機管理員 |
對 Linux 開機鏈的影響
憑證到期不影響既有安裝——已經被系統韌體信任的舊憑證只要沒被撤銷，用它簽署的 shim 仍能正常開機，這對 Linux 發行版尤其重要，因為 shim 這顆第一階段開機載入器一直是由微軟代簽，藉此讓各家發行版共用同一條信任鏈。Red Hat 的因應方式是發布同時掛有新舊兩份簽章的雙簽 shim，RHEL 9.8、RHEL 10.2 與對應的 z-stream 已經完成雙簽，RHEL 8 也預定在 6 月跟進，確保無論系統的憑證資料庫停留在 2011 版或已更新到 2023 版都能開機。
Red Hat 同時在 efivar 套件中加入新工具 sbchooser，在安裝時檢查韌體憑證資料庫是否具備對應憑證，避免裝上系統無法信任的 shim。文章也點出一個需要謹慎處理的細節：dbx 撤銷清單絕對不能把 2011 版 UEFI CA 加進去，否則會讓所有雙簽 shim 一併失效，還會波及仍依賴舊版 Option ROM 簽章的老舊硬體。日後只修補嚴重安全漏洞的新版 shim 將只用 2023 金鑰簽署，屆時系統就必須先完成韌體資料庫更新才能安裝。