strncpy很危險，但是為什麼VS2005還支援它？

之前網絡上有專門的一則新聞，描述了為什麼 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

);

此利器雖然危險，如果使用者能多加小心，應該問題不大。

是以，壓力給到了你這邊了，猿友。

最後