__STDC_LIB_EXT1__ gcc 和 clang 中的可用性

Question

由于快速搜索 Google 没有找到任何东西，我会尝试在这里问一下（因为很多人参与 gcc/clang 在这里闲逛） - [=13= 的状态如何]在gcc/clang？我们正在开发一个跨平台应用程序，我想使用 <stdio.h> 中的一些安全边界检查功能（奇迹般地在 Visual Studio 2017 上可用），但无法使用 [=25 编译代码=] 9.2。我假设 Xcode 使用的 clang 版本可能已经过时，但 Ubuntu 上的 gcc 6.3.0 表现相同。我正在尝试将 tmpnam_s 与以下示例一起使用：

#if defined(__STDC_LIB_EXT1__)
#define  __STDC_WANT_LIB_EXT1__ 1
#include <stdio.h>
#else
#error "__STDC_LIB_EXT1__ not defined"
#endif

int main(int argc, char** argv)
{
    char t[L_tmpnam_s]; 
    tmpnam_s(t, L_tmpnam_s);
    return 0;
}

但是编译失败，没有定义宏：

gcc -std=c11 test.c
test.c:5:2: error: #error "__STDC_LIB_EXT1__ not defined"
#error "__STDC_LIB_EXT1__ not defined"
^~~~~

是我做错了什么，还是这个功能集的支持很差？

Answer 1

后缀为 _s 的整套 'safe' 函数支持不佳。微软写了一组后缀为_s的函数，提交给C标准委员会进行标准化。该委员会进行了一些更改（可以说是出于必要），并创建了一份技术报告 TR 24731-1。 TR 的轻微修改版本作为可选附件 K（规范）包含在 C11 标准中，ISO/IEC 9899:2011.

您可以在 Do you use the TR-24731 "safer" functions?, especially in the notes in my answer to that question, and especially the link to the Standard C committee document N1967 Field Experience with Annex K — Bounds Checking Interfaces 的答案中找到许多肮脏的细节。

我不知道 N1967 提案的当前状态如何，但它的建议很能说明问题。 N1967 还包含指向支持 Annex K / TR-24731-1 的库的链接——列表有限。

请注意，Microsoft 未实现 C11 标准指定的库。它实现了对标准的近似，但存在关键差异。如果任何其他系统已经实现了该标准，这将更重要——但这些功能尚未以任何广泛接受的形式实现（因此，例如，GNU C 库不支持它们）。

__STDC_LIB_EXT1__ gcc 和 clang 中的可用性

__STDC_LIB_EXT1__ availability in gcc and clang

c

gcc

clang

tr24731

c11