[C 隨手記 | Visual Studio]_在Visual Studio 內使用不安全(標準)的scanf, strcpy等記憶體修改函式

最近都在寫純C的程式

 

通常都是在Linux Embed Platform做開發

但是我還是不喜歡第三方的IDE,畢竟VS用最久也最熟悉

 

通常都是VS寫一寫拿去Linux編譯在Linux上運行

 

不過前幾天有個完全純粹是軟體演算的小題目要做,因為沒有硬體相依性

所以想說拿VS試看看

 

結果打完常用的sscanf,strcpy等等…在compiler時出現以下錯誤:

 

error C4996: ‘scanf’: This function or variable may be unsafe. Consider using scanf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

 

其實之前在寫Linux Embed做單元測試時就已經注意到這個問題

不過只有稍加了解為何有此錯誤

 

根據
http://msdn.microsoft.com/zh-tw/library/8ef0s5kh.aspx

 

所指出是增強一些對記憶體操作相關指令的安全性,避免不可預期的溢位問題造成安全性問題

像是strcpy的增強函示為strcpy_s

scanf為scanf_s類似這樣…但兩者用法幾乎都沒有任何差異

 

 

解決辦法根據MSDN有三種方式

 

1.忽略老舊不安全的函式,在程式碼前方

#define _CRT_SECURE_NO_WARNINGS
2.用warning parama去關閉該warning
#pragma warning( disable : 4996 )

3.直接透過編譯器在編譯時期用更安全的函式版本代換(也就是你寫scanf,其實在編譯時自己幫你換成scanf_s),則在程式碼前方
#_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1

當然啦,前面兩種只是鴕鳥心態,若不小心沒注意到資料量造成記憶體錯誤,可能在Linux就吐給你Segment Fault了

如果更老舊的機器以及作業系統這樣的問題發生,可能就門戶大開…

當然上面所提到sscanf_s等等增強安全性函式只有在Windows底下才支援
 

所以建議在撰寫時為了保持可移植性,還是遵照標準ISO

再透過第三種方式到WINDOWS環境底下COMPILER時自動交由WINDOWS的編譯器去自動代換吧!

Leave a comment

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料