为什么 string.h 库中有这么多“不推荐使用”的函数？答案

【问题标题】：Why there is so many functions in string.h library that are "not recommended for use"?为什么 string.h 库中有这么多“不推荐使用”的函数？
【发布时间】：2013-07-21 19:56:35
【问题描述】：

关于 C 的起源，我尝试了解一些东西，为什么有些函数不建议在大多数 SO 问题中使用。像strtok 或strncpy 一样，使用它们根本不安全。在任何地方，我都会看到建议编写自己的实现。为什么标准不会将 strncpy 更改为例如 BSD strlcpy，而是留下这些“怪物”？

【问题讨论】：

“我在任何地方都看到了编写我自己的实现的建议”——不要相信他们。 strtok() -> strtok_r()，strncpy() -> memcpy()，随便。原因#1：向后兼容。原因 #2：C 标准库是标准化的（令人惊讶），但没人关心。相反，操作系统和工具链供应商不断推出自己的扩展。
如果您了解它们的特定故障或限制，它们中的许多都可以很好地使用。例如strtok 不是线程安全的，但如果你只是简单地编写一个单线程程序，那没问题。同样，strncpy 可能是“不安全的”，但可以与定义明确的输入一起使用。关键是要了解为什么某些功能已被替换或弃用。跟随 libc 等库的发展，您可以学到很多东西。
strncpy 的问题不是“定义明确的输入”的问题，而是该函数不适用于将字符串复制到其他字符串。 strncpy() 的目的是将字符串复制到 空填充的固定大小缓冲区。不是“空终止”，而是“空填充”。副本的目标不是字符串，它是一个固定大小的缓冲区。因此，如果您了解自己在做什么，strncpy() 使用起来是完全安全的，人们会告诉您“不推荐”的原因是它往往被误用作strcpy() 的更安全替代品，但事实并非如此.

标签： c string standards history

【解决方案1】：

C 是 1970 年代初期的产物，它表明了这一点。许多 iffier 库函数是在 C 用户社区非常小且仅限于学术界的时候编写的，其中大多数是有经验的程序员。

到 1989 年发布第一个标准时，这些原始库函数已经在 10 到 15 年的遗留代码中根深蒂固（其中最重要的是 Unix 操作系统及其大部分工具）。负责标准化的委员会不愿破坏现有的代码库，因此这些功能几乎按原样合并到标准中；真正改变的只是在声明中添加原型语法并在必要时将char * 更改为void *（malloc、memcpy、memset 等）。

AFAIK，自从标准化 - gets 以来，实际上只有一个库函数已从语言中删除。一个库调用造成的混乱比破坏现在近 40 年的遗留代码的前景更可怕。

【讨论】：

随心所欲地厌恶它，但这不会让它消失。我正在开发一个确实需要从龙骨上拆除和重建的系统，但这永远不会发生。这个故事的真正寓意是历史是一个严厉的情妇。

【解决方案2】：

有很多遗留的“C”和“C++”代码。如果他们从“C”运行时库中删除所有“不安全”函数，那么许多开发人员将无法升级他们的编译器，因为所有旧代码都无法再构建。

有时他们会给出“已弃用”的编译器消息（MSFT 很喜欢这个），因此您会发现并改用新的、更安全的函数。

当然，新代码应该使用“安全”函数，但我们中的许多人都坚持使用旧编译器和遗留代码来维护 :)

【讨论】：

嗯，这正是我所期望的 :) 我猜还有另一个原因，因为缺乏好的 C 库是 1) 难以编写它们 2) 大多数用 C 编写的人都使用它用于非常硬件关闭操作，因此他们实现了他们需要的最小的东西，其余的代码处理与位相关的逻辑。

【解决方案3】：

由于与仍在使用它们的“旧系统”/“代码”的历史祖先关系，它们仍然存在 - 即支持“向后兼容性”

建议使用自己的实现，让程序员自行承担风险使用自己的逻辑，因为没有人比程序员自己更了解他们的环境，例如，strtok 不是线程安全的。

【讨论】：

“没有人能比程序员自己更了解他们的环境”根本没有说服力。 C 意味着是一种编程语言，而不是汇编程序，如果我们可以像 Java 标准库一样提供程序员所需的一切，为什么每次都要重新发明轮子。

【解决方案4】：

这都是教条。使用这些函数，请注意它们与您的目标无关，因为它们可能并非在所有情况下都有效（即 strtok 和多线程），或者他们希望在使用之前/之后捕获条件（即 strncpy 和缺少终止字符） .

【讨论】：