ISO C委员会（ISO / IEC JTC1 / SC21 / WG14）已经发布了TR 24731-1并正在制定TR 24731-2：
TR 24731-1：C库扩展第I部分：边界检查接口
WG14正在制定关于更安全的C库函数的TR。该TR旨在通过添加具有缓冲区长度的额外参数来修改现有程序。最新草案在文档N1225中。原因在文档N1173中。这将成为技术报告类型2。
TR 24731-2：C库扩展第II部分：动态分配函数
WG14正在制定关于更安全的C库函数的TR。该TR旨在针对使用动态分配而不是具有缓冲区长度的额外参数的新程序。最新草案在文档N1337中。这将成为技术报告类型2。
总之，我的观点是：我不使用支持或将支持此功能的实现，也没有计划在将来使用这些函数，而且我认为 TR 没有任何积极价值。我个人认为，TR 之所以仍然以任何形式存在，仅仅是因为它受到了微软的强烈推动，尽管存在广泛反对。如果这些函数被标准化，我认为它们永远不会得到广泛应用，因为该提案已经存在几年了，却未能赢得真正的社区支持。
我喜欢Robert的回答，不过我对自己提出的问题也有些看法。
您是否使用支持TR24731-1函数的库或编译器？
不，我没有。
如果是这样，使用哪个编译器或库以及在哪些平台上？
我认为这些函数由MS Visual Studio（例如MS VC++ 2008版）提供，并且有警告鼓励您使用它们。
您是否因修复代码而使用这些函数而发现任何错误？
还没有。我不指望在我的代码中发现很多错误。我可能会在处理的其他代码中发现一些错误。但我还没有被说服。
哪些函数提供最大价值？
我喜欢printf_s()系列函数不接受'
%n'格式说明符的特点。
有哪些函数提供的价值为零或负值？
tmpfile_s()和tmpnam_s()函数令人非常失望。它们真的需要更像mkstemp()，即创建文件并打开文件以确保没有TOCTOU（检查时间与使用时间不一致）漏洞。就其现状而言，这两个函数提供非常少的价值。
我还认为strerrorlen_s()提供的价值很小。
您是否计划在未来使用该库？
我对此有两种想法。我开始编写一个库，以便实现TR 24731的功能，同时基于标准C库进行开发，但是被需要展示它正常工作的大量单元测试所困扰。我不确定是否要继续下去。我有一些代码希望在Windows上进行移植（主要是出于通用支持所有平台的倔强想法——这些代码已经在Unix派生产品上运行了几十年）。不幸的是，要使其编译时不受MSVC编译器的警告影响，我必须在代码中添加一些东西，以防止MSVC对我使用完全可靠（当小心使用时）的标准C库函数抱怨。这让我感到非常不爽。已经足够糟糕，我必须处理超过两个十年的系统发展；不得不应对别人的有趣想法（让人们无需使用TR 24731就要求他们采用）更令人恼火。这部分是我开始开发库的原因——允许我在Unix和Windows上使用相同的接口。但是我不确定我将从哪里继续下去。
您是否在追踪TR24731-2的进展？
在收集问题数据时，我并没有追踪它，直到我访问了标准网站。
asprintf()和vasprintf()函数可能很有价值；我会使用它们。对于内存流I/O函数，我不确定。C级别将strdup()标准化，这将是一个巨大的进步。对我来说，这似乎比第一部分（边界检查）接口更少争议。总的来说，我不太相信第一部分“边界检查接口”。第二部分“动态分配函数”的草案材料更好。如果由我决定，我会沿着第一部分的方向前进，但也要修订在C99标准C库中返回字符串开头的
char *的接口（例如strcpy()和strcat()），以便它们返回指向新字符串结尾的空字节的指针。这将使一些常见的惯用语（例如重复将字符串连接到另一个字符串末尾）更加高效，因为它将使避免重复使用strcat()的代码所展示的二次行为变得微不足道。所有替换都将确保输出字符串以null结尾，就像TR24731版本那样。我不完全反对检查接口的想法，也不反对异常处理函数。这是一个棘手的问题。更新（2011-05-08）
另请参阅此问题。遗憾的是，对于TR24731函数的有用性来说，一些函数的定义在Microsoft实现和标准之间存在差异，使它们对我来说毫无用处。我的回答引用了
vsnprintf_s()。例如，TR 24731-1表示
vsnprintf_s()的接口如下：
#define __STDC_WANT_LIB_EXT1__ 1
#include <stdarg.h>
#include <stdio.h>
int vsnprintf_s(char * restrict s, rsize_t n,
const char * restrict format, va_list arg);
不幸的是，MSDN 上对 vsnprintf_s() 接口的说明如下：
int vsnprintf_s(
char *buffer,
size_t sizeOfBuffer,
size_t count,
const char *format,
va_list argptr
);
参数
需要注意的是，这不仅仅是类型映射的问题：固定参数的数量是不同的，因此无法调和。另外，对于具有 'sizeOfBuffer' 和 'count' 的功能，我也不清楚（也许标准委员会也不清楚）有何好处；看起来像是相同的信息重复了两遍（或者至少通常情况下，两个参数将使用相同的值编写代码）。
scanf_s() 及其相关函数也存在问题。 Microsoft 指出缓冲区长度参数的类型为 unsigned（明确表示“大小参数的类型为 unsigned，而不是 size_t”）。相比之下，在附录 K 中，大小参数的类型为 rsize_t，这是 size_t 的限制变体（rsize_t 是 size_t 的另一个名称，但 RSIZE_MAX 比 SIZE_MAX 小）。因此，调用 scanf_s() 的代码必须在 Microsoft C 和标准 C 中编写不同的代码。
最初，我计划使用“安全”函数作为一种在 Windows 和 Unix 上使代码能够编译而无需编写条件代码的方式。由于 Microsoft 和 ISO 函数并不总是相同，因此现在放弃这种计划已经是时候了。
vsnprintf() 的更改在 Visual Studio 2015 的 vsnprintf() 文档中，注意到接口发生了变化：
从 UCRT 开始（Visual Studio 2015 和 Windows 10），
vsnprintf不再与_vsnprintf相同。vsnprintf函数符合 C99 标准；_vnsprintf保留了向后兼容性。
然而，Microsoft vsnprintf_s() 的接口未更改。
localtime_s() 的 C11 标准变体在 ISO/IEC 9899:2011 附录 K.3.8.2.4 中定义为：
struct tm *localtime_s(const time_t * restrict timer,
struct tm * restrict result);
相对于MSDN版本的localtime_s()，定义如下：
errno_t localtime_s(struct tm* _tm, const time_t *time);
同时还有 POSIX 变种localtime_r()，其定义如下：
struct tm *localtime_r(const time_t *restrict timer,
struct tm *restrict result);
C11标准和POSIX函数除了名称之外是等效的。尽管与C11标准共享名称，但Microsoft函数在接口上有所不同。
另一个差异的例子是Microsoft的strtok_s()和Annex K的strtok_s()：
char *strtok_s(char *strToken, const char *strDelimit, char **context);
vs：
char *strtok_s(char * restrict s1, rsize_t * restrict s1max, const char * restrict s2, char ** restrict ptr);
strtok_s()的参数列表与POSIX的strtok_r()兼容 - 因此，如果更改函数名称（例如通过宏），则对这些调用可以实现互换 - 但标准C（Annex K）版本与两者都不同，并多了一个额外的参数。qsort_r()不同的问题有一个答案，还讨论了由Microsoft定义的qsort_s()和TR24731-1定义的qsort_s()——接口也是不同的。vasprintf()函数及其相关函数可能非常有用。文档中提到了一些Annex K函数的现有实现，但它们并不广泛使用（如果您感兴趣，可以通过文档找到它们）。
文档最后建议：
因此，我们建议将Annex K从下一版C标准中删除，或者弃用然后删除。
我支持这个建议。
C18标准没有改变Annex K的状态。有一篇论文N2336主张对Annex K进行一些修改，修复其缺陷而不是完全删除它。
好的，现在介绍一下TR24731-2：
是的，我自从在glibc中发现后就一直使用asprintf()/vasprintf()，而且我非常支持它们。
为什么呢？
因为它们一次又一次地能精确地提供我所需要的东西：一种强大、灵活、安全并且（相对）易于使用的格式化任何文本为新分配字符串的方法。
我也非常支持memstream函数：open_memstream()（而不是fmemopen()!!!）像asprintf()一样，会为您分配一个足够大的缓冲区，并给您一个FILE*来执行打印操作，这样您的打印函数可以完全不知道它们是在打印到字符串还是文件中，而且您可以简单地忘记需要多少空间。
vasprintf，而是一个“通用”的vformat函数，它接受一个int(*func)(void*,size_t,char const*)和一个void*，除了通常的vprintf参数之外，并为要输出的每个“span”调用提供的函数[如果函数返回非零值，则提前返回]。可以通过这样的函数合成自动分配sprintf，但通用版本也与自定义分配器兼容。 - supercatstdio 变体可以让您指定自己的读/写函数。例如，您可以执行 FILE *fp = ffunopen(myreadfunc, mywritefunc)，然后调用 fprintf 或 任何 stdio 函数，并调用您的回调函数。我还看到过至少一个实现了具有内置自动分配的 fmemopen 变体 - 这意味着您可以为任何输出调用序列获得自动分配，而不仅仅是 *printf。 - Steve SummitFILE*包含一个指向函数表的指针将非常有用，但我的主要观点是库例程不应依赖于malloc，而是允许用户代码使用最适合预期使用情况的任何方式来管理内存。 - supercat
strlen()添加到代码中”的含义。有时候strlen()显然不是正确的答案，比如当将缓冲区传递给I/O函数（例如gets_s()）时。但也许你可以详细说明一下你的想法？ - Jonathan Lefflerrealloc()，因为需要保护的函数不会分配内存。例如，strcpy()函数不会进行内存分配；即使有垃圾回收，你也不能合理地修改它以执行内存分配，因为人们通常不使用返回值，而是使用作为第一个参数传递给strcpy()的值进行进一步操作。gets()和strcat()也存在类似的问题。至少它们返回一个可能指向重新分配空间的char *（并不保证参数已经分配）。_ […继续…]_ - Jonathan Lefflersprintf()这样不返回char *的函数更糟糕；它们没有办法告诉调用代码它们“重新分配”了结果所在的内存。请注意，TR 24731-2未能成为C11的原因之一是它们将是显示进行内存分配的第一个函数，除了malloc()等函数外。请花时间研究这些函数的功能、Annex K / TR 24731-1 函数的功能、它们这样做的原因等等。做出这些决策有一些合理的理由。 - Jonathan Leffler