c語言 那些不安全的庫函式
c和c++不能夠自動地做邊界檢查，邊界檢查的代價是效率。一般來講，c 在大多數情況下注重效率。然而，獲得效率的代價是，c 程式設計師必須十分警覺以避免緩衝區溢位問題。
c語言標準庫中的許多字串處理和io流讀取函式是導致緩衝區溢位的罪魁禍首。我們有必要了解這些函式，在程式設計中多加小心。
一、字串處理函式
strcpy()我們也可以使用strncpy來完成同樣的目的：
strncpy (dst, src, dst_size-1);但是！ strncpy()也不完全安全,也有可能把事情搞糟。即使「安全」的呼叫有時會留下未終止的字串，或者會發生微妙的相差一位錯誤。
確保 strcpy() 不會溢位的另一種方式是，在需要它時就分配空間，確保通過在源字串上呼叫 strlen() 來分配足夠的空間。
strcat() 函式非常類似於 strcpy()，除了它可以將乙個字串合併到緩衝區末尾。它也有乙個類似的、更安全的替代方法 strncat()。如果可能，使用 strncat() 而不要使用 strcat()。
函式 sprintf() 和 vsprintf() 是用來格式化文字和將其存入緩衝區的通用函式。它們可以用直接的方式模仿 strcpy() 行為。換句話說，使用 sprintf() 和 vsprintf() 與使用 strcpy() 一樣，都很容易對程式造成緩衝區溢位。
sprintf() 的許多版本帶有使用這種函式的更安全的方法。可以指定格式字串本身每個自變數的精度。sprintf 採用」 * 」來占用乙個本來需要乙個指定寬度或精度的常數數字的位置，而實際的寬度或精度就可以和其它被列印的變數一樣被提供出來。
例如：
二、字元讀取函式
gets()
永遠不要使用 gets()。
該函式從標準輸入讀入使用者輸入的一行文字，它在遇到 eof 字元或換行字元之前，不會停止讀入文字。也就是：gets() 根本不執行邊界檢查。因此，使用 gets() 總是有可能使任何緩衝區溢位。
作為乙個替代方法，可以使用方法 fgets()。它可以做與 gets() 所做的同樣的事情，但它接受用來限制讀入字元數目的大小引數，因此，提供了一種防止緩衝區溢位的方法。
如果在迴圈中使用這些函式，確保檢查緩衝區邊界
scanf()系列 : sscanf()、fscanf()、vfscanf()、vscanf()、vsscanf()
scanf系列的函式也設計得很差。目的地緩衝區也可能會發生溢位。
同樣地，我們用設定寬度也可以解決這個問題。
getenv()
使用系統呼叫 getenv() 的最大問題是您從來不能假定特殊環境變數是任何特定長度的。
三、使用安全版本的**庫
微軟對於有緩衝溢位危險的api使用其開發的安全版本的庫來替代。 safecrt自visual studio 2005起開始支援。當**中使用了禁用的危險的crt函式，visual studio 2005編譯時會報告相應警告資訊，以提醒開發人員考慮將其替代為safe crt中更為安全。
有關字串拷貝的api
例如：strcpy, wcscpy等
替代的safe crt函式：strcpy_s
有關字串合併的api
例如：strcat, wcscat等
替代的safe crt函式：strcat_s
有關sprintf的api
例如：sprintf, swprintf等
替代的safe crt函式：
_snprintf_s
_snwprintf_s
其它被禁用的api還有scanf, strtok, gets, itoa等等。 」n」系列的字串處理函式，例如strncpy等，也在被禁用之列。
c語言不安全庫 C語言 一些不安全的庫函式
那些不安全的庫函式 c 和 c 不能夠自動地做邊界檢查，邊界檢查的代價是效率。一般來講，c 在大多數情況下注重效率。然而，獲得效率的代價是，c 程式設計師必須十分警覺以避免緩衝區溢位問題。c語言標準庫中的許多字串處理和io流讀取函式是導致緩衝區溢位的罪魁禍首。我們有必要了解這些函式，在程式設計中多加...
執行緒不安全
背景 執行緒不安全 sleep 模擬網路延遲 後多執行緒併發訪問同乙個資源 方法1 同步 塊 語法 synchronized 同步鎖 catch interruptedexception e 方法2 同步方法 使用synchronizd修飾的方法，就叫同步方法，保證a執行緒執行該方法的時候，其他執行...
關於C語言指標的不安全操作
昨天，剛剛請教了劉老師，對c語言指標的不安全操作有了乙個更深刻的認識。初學指標的人，往往對char p hello world 式的賦值認為理所當然，最造成的 該記憶體不能written 式的錯誤不知所措。其實那是乙個指標指向了字串常量的開始位址，該位址的內容是唯讀的，自然不能write.指標 首先...