代碼安全性和健壯性：如何在if和assert中作選擇？

道哥的第 023 篇原創

目錄

• 1、前言
• 2、assert 斷言
  • assert 是一個宏，不是一個函數
• 3、if VS assert
  • 1. 使用 if 語句來檢查
  • 2. 使用 assert 斷言來檢查
  • 3. 你喜歡哪個？
  • 4. assert 的本質
  • 5. if-else 的本質
  • 6. 我喜歡的版本
• 5、總結

1、前言

咱們在擼代碼的時候，常常須要對代碼的安全性進行檢查，例如：

1. 指針是否爲空？
2. 被除數是否爲 0？
3. 函數調用的返回結果是否有效？
4. 打開一個文件是否成功？

對這一類的邊界條件進行檢查的手段，通常都是使用 if 或者 assert 斷言，不管使用哪個，均可以達到檢查的目的。那麼是否就意味着：這二者能夠隨便使用，想起來哪一個就用哪一個？

這篇小短文咱們就來掰扯掰扯：在不一樣的場景下，究竟是應該用 if，仍是應該使用 assert 斷言？

寫這篇文章的時候，我想起了孔乙己老先生的那個問題：茴香豆的「茴」字有幾種寫法？

彷佛咱們沒有必要來糾結應該怎麼選擇，由於都可以實現想要的功能。之前我也是這麼想的，可是，如今我不這麼認爲。

成爲技術大牛、拿到更好的offer，也許就在這些細微之間就分出了勝負。

2、assert 斷言

剛纔，我問了下旁邊的一位工做 5 年多的嵌入式開發者：if 和 assert 如何選擇？他說：assert 是幹什麼的？！

看來，有必要先簡單說一下 assert 斷言。

assert() 的原型是：

void assert(int expression);

1. 若是宏的參數求值結果爲非零值，則不作任何操做（no action）；
2. 若是宏的參數是零值，就打印診斷消息，而後調用abort()。

例以下面的代碼：

#include <assert.h>
int my_div(int a, int b)
{
    assert(0 != b);
    return a / b;
}

1. 當 b 不爲 0 時，assert 斷言什麼都不作，程序往下執行；
2. 當 b 爲 0 時，assert 斷言就打印錯誤信息，而後終止程序；

從功能上來講，assert(0 != b); 與下面的代碼等價：

if (0 == b)
{
    fprintf(stderr, "b is zero...");
    abort();
}

assert 是一個宏，不是一個函數

在 assert.h 頭文件中，有以下定義：

#ifdef NDEBUG
    #define assert(condition) ((void)0)
#else
    #define assert(condition) /*implementation defined*/
#endif

既然是宏定義，說明是在預處理的時候進行宏替換。(關於宏的更多內容，能夠看一下這篇文章:提升代碼逼格的利器：宏定義-從入門到放棄)。

從上面的定義中能夠看到：

1. 若是定義了宏 NDEBUG，那麼 assert() 宏將不作什麼動做，也就是至關於一條空語句： (void)0;，當在 release 階段編譯代碼的時候，都會在編譯選項中(Makefile)定義這個宏。
2. 若是沒有定義宏 NDEBUG，那麼 assert() 宏將會把一些檢查代碼進行替換，咱們在開發階段執行 debug 模式編譯時，通常都會屏蔽掉這 NDEBUG 這個宏。

3、if VS assert

仍是以一個代碼片斷來描述問題，以場景化來討論比較容易理解。

// brief: 把兩個短字符串拼接成一個字符串
char *my_concat(char *str1, char *str2)
{
    int len1 = strlen(str1);
    int len2 = strlen(str2);
    int len3 = len1 + len2;
    char *new_str = (char *)malloc(len3 + 1);
    memset(new_str, 0 len3 + 1);
    sprintf(new_str, "%s%s", str1, str2);
    return new_str;
}

若是一個開發人員寫出上面的代碼，必定會被領導約談的！它存在下面這些問題：

1. 沒有對輸入參數進行有效性檢查；
2. 沒有對 malloc 的結果進行檢查；
3. sprintf 的效率很低；
4. ...

1. 使用 if 語句來檢查

char *my_concat(char *str1, char *str2)
{
    if (!str1 || !str2)  // 參數錯誤
        return NULL;
        
    int len1 = strlen(str1);
    int len2 = strlen(str2);
    int len3 = len1 + len2;
    char *new_str = (char *)malloc(len3 + 1);
    
    if (!new_str)   // 申請堆空間失敗
        return NULL;
    
    memset(new_str, 0 len3 + 1);
    sprintf(new_str, "%s%s", str1, str2);
    return new_str;
}

2. 使用 assert 斷言來檢查

char *my_concat(char *str1, char *str2)
{
    // 確保參數正確
    assert(NULL != str1);
    assert(NULL != str2);
    
    int len1 = strlen(str1);
    int len2 = strlen(str2);
    int len3 = len1 + len2;
    char *new_str = (char *)malloc(len3 + 1);
    
    // 確保申請堆空間成功
    assert(NULL != new_str);
    
    memset(new_str, 0 len3 + 1);
    sprintf(new_str, "%s%s", str1, str2);
    return new_str;
}

3. 你喜歡哪個？

首先聲明一點：以上這 2 種檢查方式，在實際的代碼中都很常見，從功能上來講彷佛也沒有什麼影響。所以，沒有嚴格的錯與對之分，不少都是依賴於每一個人的偏好習慣不一樣而已。

（1） assert 支持者

我做爲 my_concat() 函數的實現者，目的是拼接字符串，那麼傳入的參數必須是合法有效的，調用者須要負責這件事。若是傳入的參數無效，我會表示十分的驚訝！怎麼辦：崩潰給你看！

（2）if 支持者

我寫的 my_concat() 函數十分的健壯，我就預料到調用者會亂搞，故意的傳入一些無效參數，來測試個人編碼水平。沒事，來吧，我能夠處理任何狀況！

這兩個派別的理由彷佛都很充足！那究竟該如何選擇？難道真的的跟着感受走嗎？

假設咱們嚴格按照常規的流程去開發一個項目：

1. 在開發階段，編譯選項中不定義 NDEBUG 這個宏，那麼 assert 就發揮做用；
2. 項目發佈時，編譯選項中定義了 NDEBUG 換個宏，那麼 assert 就至關於空語句；

也就是說，只有在 debug 開發階段，用 assert 斷言纔可以正確的檢查到參數無效。而到了 release 階段，assert 不起做用，若是調用者傳遞了無效參數，那麼程序只有崩潰的命運了。

這說明什麼問題？是代碼中存在 bug？仍是代碼寫的不夠健壯？

從我我的的理解上看，這壓根就是單元測試沒有寫好，沒有測出來參數無效的這個 case！

4. assert 的本質

assert 就是爲了驗證有效性，它最大做用就是：在開發階段，讓咱們的程序儘量地 crash。每一次的 crash，都意味着代碼中存在着 bug，須要咱們去修正。

當咱們寫下一個 assert 斷言的時候，就說明：斷言失敗的這種狀況是不能夠的，是不被容許的。必須保證斷言成功，程序才能繼續往下執行。

5. if-else 的本質

if-else 語句用於邏輯處理，它是爲了處理各類可能出現的狀況。就是說：每個分支都是合理的，是容許出現的，咱們都要對這些分支進行處理。

6. 我喜歡的版本

char *my_concat(char *str1, char *str2)
{
    // 參數必須有效
    assert(NULL != str1);
    assert(NULL != str2);
    
    int len1 = strlen(str1);
    int len2 = strlen(str2);
    int len3 = len1 + len2;
    char *new_str = (char *)malloc(len3 + 1);
    
    // 申請堆空間失敗的狀況，是可能的，是容許出現的狀況。
    if (!new_str)
        return NULL;
    
    memset(new_str, 0 len3 + 1);
    sprintf(new_str, "%s%s", str1, str2);
    return new_str;
}

對於參數而言：我認爲傳入的參數必須是有效的，若是出現了無效參數，說明代碼中存在 bug，不容許出現這樣的狀況，必須解決掉。

對於資源分配結果(malloc 函數)而言：我認爲資源分配失敗是合理的，是有可能的，是容許出現的，並且我也對這個狀況進行了處理。

固然了，並非說對參數檢查就要使用 assert，主要是根據不一樣的場景、語義來判斷。例以下面的這個例子：

int g_state;
void get_error_str(bool flag)
{
    if (TRUE == flag)
    {
        g_state = 1;
        assert(1 == g_state); // 確保賦值成功
    }
    else
    {
        g_state = 0;
        assert(0 == g_state); // 確保賦值成功
    }
}

flag 參數表明不一樣的分支狀況，而賦值給 g_state 以後，必須保證賦值結果的正確性，所以使用 assert 斷言。

5、總結

這篇文章分析了 C 語言中比較晦澀、模糊的一個概念，彷佛有點虛無縹緲，可是的確又須要咱們停下來仔細考慮一下。

若是有些場景，實在拿捏很差，我就會問本身一個問題：

這種狀況是否被容許出現？

不容許：就用 assert 斷言，在開發階段就儘可能找出全部的錯誤狀況；

容許：就用 if-else，說明這是一個合理的邏輯，須要進行下一步處理。

---

【原創聲明】

轉載：歡迎轉載，但未經做者贊成，必須保留此段聲明，必須在文章中給出原文鏈接。

---

不吹噓，不炒做，不浮誇，認真寫好每一篇文章！

歡迎 轉發、分享給身邊的技術朋友，道哥在此表示衷心的感謝！ 轉發的 推薦語已經幫您想好了：

道哥總結的這篇總結文章，寫得很用心，對個人技術提高頗有幫助。好東西，要分享！

---

推薦閱讀

C語言指針-從底層原理到花式技巧，用圖文和代碼幫你講解透徹
一步步分析-如何用C實現面向對象編程
我最喜歡的進程之間通訊方式-消息總線
物聯網網關開發：基於MQTT消息總線的設計過程(上)
提升代碼逼格的利器：宏定義-從入門到放棄
原來gdb的底層調試原理這麼簡單
利用C語言中的setjmp和longjmp，來實現異常捕獲和協程
關於加密、證書的那些事
深刻LUA腳本語言，讓你完全明白調試原理