歷經六年、360 多個修補程式後，Linux 移除 strncpy API （★ 102 分）
Linux 7.2 已把 strncpy API（應用程式介面）從 Linux 核心中移除。strncpy() 是 C 語言中用來複製指定位元組數的字串函式，長期被視為不建議使用；這次在約六年、362 個提交後，核心內已不再有任何 strncpy 使用處，因此正式刪除這個介面與最後的 CPU 架構專用實作。
文章指出，strncpy 多年來一直是錯誤來源，主要問題在於它對 NUL 字元（值為 0、常用來標示 C 字串結尾）的處理很反直覺：它不一定會產生 NUL 結尾，卻又可能對目的地緩衝區進行多餘補零，造成效能浪費。Linux 核心接下來會依情境改用更明確的函式，例如 strscpy() 用於需要 NUL 結尾的目的地，strscpy_pad() 用於需要 NUL 結尾且補零的情境，strtomem_pad() 用於不以 NUL 結尾的固定寬度欄位，memcpy_and_pad() 用於有界限且明確補齊的複製，memcpy() 則用於已知長度的記憶體複製。
討論中不少開發者補充 strncpy 的歷史脈絡：它原本來自早期 UNIX 核心，用於處理目錄項目中「2 位元組 inode（檔案系統用來識別檔案的索引節點）加上 14 位元組、補零但不以 NUL 結尾的檔名欄位」，並不是為了一般安全字串複製而設計。也有人提醒，所謂 360 多個修補並不代表發現 360 多個漏洞，而是移除 360 多處使用；但多位有經驗的 C 開發者表示，在程式碼審查中看到 strncpy 往往就是高風險訊號。
討論也延伸到 C 字串設計本身。許多人認為 NUL 結尾字串是安全與效能問題的根源之一，因為只要結尾字元遺失，標準字串函式就可能一路讀到配置範圍外，引發記憶體越界與資安風險；此外，在迴圈中反覆呼叫 strlen() 也可能讓原本 O(N) 的操作變成 O(N^2)。也有留言比較 Pascal 式長度前綴字串、帶長度的緩衝區結構，以及 strlcpy；但其他人指出 Linux 核心曾經有 strlcpy，後來因介面設計考量改採 strscpy。
整體討論把這次移除視為典型的系統工程長期清理工作：不炫目，但能逐步降低核心中模糊、易誤用介面的風險。也有人提到是否可用大型語言模型（LLM, Large Language Model）自動完成這類替換；反方則提醒，C 的記憶體安全錯誤往往很細微，而模型訓練資料中也包含大量不安全寫法，因此仍需要熟悉語意與邊界條件的人類審查。
👥 76 則討論、評論 💬
https://news.ycombinator.com/item?id=48612943