之前网络上有专门的一则新闻，描述了为什么 strncpy 如此危险，在此之后，至少有一个人要求Visual Studio 开发团队移除对这个危险函数的支持。考虑到对函数的持续支持，要求编译器制造商对使用该编译器编译的程序中的任何缺陷负责。

嗯，一方面，虽然如果使用不当，strncpy确实很危险，但它仍然是一个有效的函数，我最初的讨论解释了strncpy 背后的历史以及它仍然有用得非常具体的场景。

碰巧的是，大多数人并没有按照预期的方式使用该函数，而是将其视为一种“具有字符限制的复制字符串”函数，但事实并非如此。

另一方面，仅仅因为某些东西是危险的并不意味着它不应该被支持。指针和强制转换很危险，但我不认为它们很快就会从 C 或 C++ 中消失。

第三，对 strncpy 的支持是由 C 标准强制要求的。如果你删除了它，你就不能再称自己为 C 编译器了。（更不用说破坏与使用 strncpy 函数的现有源代码的兼容性了。如果你买了一个所谓的C编译器，发现它不能编译一大类有效的C程序，你会怎么想？）

所以，Visual Studio 团队将继续支持strncpy。

总结

我们来具体看看这个函数的警示：
函数原型：
char *strncpy(
char *strDest,
const char *strSource,
size_t count
);
strncpy 不会检查 strDest 是否有足够的空间;这使其成为缓冲区溢出的潜在原因。count 参数限制复制的字符数;它不是对strDest大小的限制。

所以，我们应该明白，为什么VS增加了自己的安全版本：
errno_t strncpy_s(
char *strDest,
size_t numberOfElements,
const char *strSource,
size_t count
);

此利器虽然危险，如果使用者能多加小心，应该问题不大。
所以，压力给到了你这边了，猿友。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《If strncpy is so dangerous, why does Visual Studio 2005 still support it?》