【资料图】

关于使用更安全的memcpy_s而不禁用危险的memcpy或更新memcpy源码的问题，以下是一些考虑因素：首先，memcpy_s并不是绝对安全的实现。尽管它要求您提供一个长度参数来确保不会发生溢出或越界问题，但这个长度仍然需要您自己提供，而不是通过标准库的各种黑魔法进行判断。如果您传入的长度有问题，这些所谓的"安全函数"仍然可能悄无声息地引发错误，就像非安全版本一样。而且，对于返回的错误，您可能并不会每次都检查，尤其是在您确信目标位置足够大的情况下，而这正是许多程序中出现越界访问的根本原因之一。其次，在许多需要大量数据复制的情况下，特别是涉及到IO操作时，频繁进行长度判断会严重影响性能，尤其是在数据长度每次都不同的情况下。这可能导致分支预测出现大量错误，严重降低性能。刚好，我这里有嵌入式学习路线，毕设，各种项目，需要留个6。最后，还有可移植性的问题。目前只有Windows平台强制推广使用这类安全函数，而在其他平台上，对于C运行库来说，这种安全函数并不是必需的。如果您编写的代码需要使用这些函数，而其他人仍在使用旧版本的GCC 编译器，可能会告诉您这些代码无法编译。这就需要您在编写代码时进行区分，以编写适应两种情况的代码。综上所述，考虑到memcpy_s的安全性并非绝对，性能损耗以及可移植性问题，因此在是否禁用危险的memcpy或更新memcpy源码方面，需要权衡利弊并根据具体情况做出决策。