為什么 gcc（或 glibc）沒有實現 _s 函數？

Question

_s 函數，例如scanf_s ， printf_s似乎是可選標准。 MSVC 已經實現了這些功能，但是 gcc 沒有。

不實現安全功能是否有具體原因？ glibc 的scanf是否足夠安全？

Answer 1

_s函數是可選的（ C11 標准的附件 K ）。 它們被廣泛認為“不是很有益”。

在我的問題的答案中，您是否使用 TR-24731“安全”功能？ ，您可以找到有關標准規范哪里存在問題的信息，例如標准和 Microsoft 實現之間的關鍵差異。 TR 24731-1 是 C 標准委員會的技術報告。 該報告幾乎是逐字逐句地合並到 C11 標准中作為（可選但“規范性”）附件 K 中的一個額外的以前省略的功能 IIRC。還有用於不同功能集的 TR 24731-2 - 沒有_s后綴. 由於一系列不同的原因，它遇到了阻力。

此外， C 標准委員會提出了一項建議，即在標准的下一次修訂中刪除這些功能：

• N1967附件 K 現場經驗 — 邊界檢查接口

那篇論文是對 TR-24731 ( *_s() ) 函數沒有被廣泛實現的原因的直接而引人注目的閱讀。

主要原因包括：

• 問題只被發現一次，然后修復，然后*_s()函數是不必要的。
• 這使得測試*_s()函數或使用它們的代碼變得非常困難。
• 將新功能集成到舊代碼中並不容易（這是最大的好處）。
• 這些功能固有地通過廣泛但冗余的檢查減慢了軟件的速度。

有關更多詳細信息，請參閱論文。 論文以以下部分結束：

建議的技術勘誤表

盡管自最初的提案以來已有十多年的時間，並且自 ISO/IEC TR 24731-1:2007 批准以來已近十年，並且自將邊界檢查接口引入 C 標准以來已近五年，但沒有出現可行的符合性實現. API 繼續存在爭議，實施者繼續拒絕實施請求。

邊界檢查接口的設計雖然是善意的，但有太多的問題需要糾正。 與依賴既定方法或現代技術相比，使用 API 已被視為導致質量更差、安全性更低的軟件。 更有效和更少侵入性的方法已變得司空見慣，並且通常受到用戶和安全專家等人的青睞。

因此，我們建議附件 K 要么從 C 標准的下一個修訂版中刪除，要么棄用然后刪除。