訂閱
糾錯(cuò)
加入自媒體

代碼安全性如何在if和assert中做選擇?

一、前言

二、assert 斷言

三、if VS assert

五、總結(jié)

一、前言

我們?cè)跀]代碼的時(shí)候,經(jīng)常需要對(duì)代碼的安全性進(jìn)行檢查,例如:

1. 指針是否為空?

2. 被除數(shù)是否為 0?

3. 函數(shù)調(diào)用的返回結(jié)果是否有效?

4. 打開一個(gè)文件是否成功?

對(duì)這一類的邊界條件進(jìn)行檢查的手段,一般都是使用 if 或者 assert 斷言,無論使用哪一個(gè),都可以達(dá)到檢查的目的。那么是否就意味著:這兩者可以隨便使用,想起來哪個(gè)就用哪個(gè)?

這篇小短文我們就來掰扯掰扯:在不同的場景下,到底是應(yīng)該用 if,還是應(yīng)該使用 assert 斷言?

寫這篇文章的時(shí)候,我想起了孔乙己老先生的那個(gè)問題:茴香豆的“茴”字有幾種寫法?

似乎我們沒有必要來糾結(jié)應(yīng)該怎么選擇,因?yàn)槎寄軌驅(qū)崿F(xiàn)想要的功能。以前我也是這么想的,但是,現(xiàn)在我不這么認(rèn)為。

成為技術(shù)大牛、拿到更好的offer,也許就在這些細(xì)微之間就分出了勝負(fù)。

二、assert 斷言

剛才,我問了下旁邊的一位工作 5 年多的嵌入式開發(fā)者:if 和 assert 如何選擇?他說:assert 是干什么的?!

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

assert() 的原型是:

void assert(int expression);

1. 如果宏的參數(shù)求值結(jié)果為非零值,則不做任何操作(no action);
2. 如果宏的參數(shù)是零值,就打印診斷消息,然后調(diào)用abort()。

例如下面的代碼:

#include

1. 當(dāng) b 不為 0 時(shí),assert 斷言什么都不做,程序往下執(zhí)行;
2. 當(dāng) b 為 0 時(shí),assert 斷言就打印錯(cuò)誤信息,然后終止程序;

從功能上來說,assert(0 != b); 與下面的代碼等價(jià):

if (0 == b){    fprintf(stderr, "b is zero...");    abort();}
assert 是一個(gè)宏,不是一個(gè)函數(shù)

在 assert.h 頭文件中,有如下定義:

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

既然是宏定義,說明是在預(yù)處理的時(shí)候進(jìn)行宏替換。(關(guān)于宏的更多內(nèi)容,可以看一下這篇文章:提高代碼逼格的利器:宏定義-從入門到放棄)。

從上面的定義中可以看到:

如果定義了宏 NDEBUG,那么 assert() 宏將不做什么動(dòng)作,也就是相當(dāng)于一條空語句:(void)0;,當(dāng)在 release 階段編譯代碼的時(shí)候,都會(huì)在編譯選項(xiàng)中(Makefile)定義這個(gè)宏。如果沒有定義宏 NDEBUG,那么 assert() 宏將會(huì)把一些檢查代碼進(jìn)行替換,我們?cè)陂_發(fā)階段執(zhí)行 debug 模式編譯時(shí),一般都會(huì)屏蔽掉這 NDEBUG 這個(gè)宏。三、if VS assert

還是以一個(gè)代碼片段來描述問題,以場景化來討論比較容易理解。

// brief: 把兩個(gè)短字符串拼接成一個(gè)字符串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;}

如果一個(gè)開發(fā)人員寫出上面的代碼,一定會(huì)被領(lǐng)導(dǎo)約談的!它存在下面這些問題:

沒有對(duì)輸入?yún)?shù)進(jìn)行有效性檢查;沒有對(duì) malloc 的結(jié)果進(jìn)行檢查;sprintf 的效率很低;...1. 使用 if 語句來檢查char *my_concat(char *str1, char *str2){    if (!str1 || !str2)  // 參數(shù)錯(cuò)誤        return NULL;            int len1 = strlen(str1);    int len2 = strlen(str2);    int len3 = len1 + len2;    char *new_str = (char *)malloc(len3 + 1);        if (!new_str)   // 申請(qǐng)堆空間失敗        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){    // 確保參數(shù)正確    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);        // 確保申請(qǐng)堆空間成功    assert(NULL != new_str);        memset(new_str, 0 len3 + 1);    sprintf(new_str, "%s%s", str1, str2);    return new_str;}

3. 你喜歡哪一個(gè)?

首先聲明一點(diǎn):以上這 2 種檢查方式,在實(shí)際的代碼中都很常見,從功能上來說似乎也沒有什么影響。因此,沒有嚴(yán)格的錯(cuò)與對(duì)之分,很多都是依賴于每個(gè)人的偏好習(xí)慣不同而已。

(1) assert 支持者

我作為 my_concat() 函數(shù)的實(shí)現(xiàn)者,目的是拼接字符串,那么傳入的參數(shù)必須是合法有效的,調(diào)用者需要負(fù)責(zé)這件事。如果傳入的參數(shù)無效,我會(huì)表示十分的驚訝!怎么辦:崩潰給你看!

(2)if 支持者

我寫的 my_concat() 函數(shù)十分的健壯,我就預(yù)料到調(diào)用者會(huì)亂搞,故意的傳入一些無效參數(shù),來測(cè)試我的編碼水平。沒事,來吧,我可以處理任何情況!

這兩個(gè)派別的理由似乎都很充足!那究竟該如何選擇?難道真的的跟著感覺走嗎?

假設(shè)我們嚴(yán)格按照常規(guī)的流程去開發(fā)一個(gè)項(xiàng)目:

1. 在開發(fā)階段,編譯選項(xiàng)中不定義 NDEBUG 這個(gè)宏,那么 assert 就發(fā)揮作用;

2. 項(xiàng)目發(fā)布時(shí),編譯選項(xiàng)中定義了 NDEBUG 換個(gè)宏,那么 assert 就相當(dāng)于空語句;

也就是說,只有在 debug 開發(fā)階段,用 assert 斷言才能夠正確的檢查到參數(shù)無效。而到了 release 階段,assert 不起作用,如果調(diào)用者傳遞了無效參數(shù),那么程序只有崩潰的命運(yùn)了。

這說明什么問題?是代碼中存在 bug?還是代碼寫的不夠健壯?

從我個(gè)人的理解上看,這壓根就是單元測(cè)試沒有寫好,沒有測(cè)出來參數(shù)無效的這個(gè) case!

4. assert 的本質(zhì)

assert 就是為了驗(yàn)證有效性,它最大作用就是:在開發(fā)階段,讓我們的程序盡可能地 crash。每一次的 crash,都意味著代碼中存在著 bug,需要我們?nèi)バ拚?/p>

當(dāng)我們寫下一個(gè) assert 斷言的時(shí)候,就說明:斷言失敗的這種情況是不可以的,是不被允許的。必須保證斷言成功,程序才能繼續(xù)往下執(zhí)行。

5. if-else 的本質(zhì)

if-else 語句用于邏輯處理,它是為了處理各種可能出現(xiàn)的情況。就是說:每一個(gè)分支都是合理的,是允許出現(xiàn)的,我們都要對(duì)這些分支進(jìn)行處理。

6. 我喜歡的版本char *my_concat(char *str1, char *str2){    // 參數(shù)必須有效    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);        // 申請(qǐng)堆空間失敗的情況,是可能的,是允許出現(xiàn)的情況。    if (!new_str)        return NULL;        memset(new_str, 0 len3 + 1);    sprintf(new_str, "%s%s", str1, str2);    return new_str;}

對(duì)于參數(shù)而言:我認(rèn)為傳入的參數(shù)必須是有效的,如果出現(xiàn)了無效參數(shù),說明代碼中存在 bug,不允許出現(xiàn)這樣的情況,必須解決掉。

對(duì)于資源分配結(jié)果(malloc 函數(shù))而言:我認(rèn)為資源分配失敗是合理的,是有可能的,是允許出現(xiàn)的,而且我也對(duì)這個(gè)情況進(jìn)行了處理。

當(dāng)然了,并不是說對(duì)參數(shù)檢查就要使用 assert,主要是根據(jù)不同的場景、語義來判斷。例如下面的這個(gè)例子:

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 參數(shù)代表不同的分支情況,而賦值給 g_state 之后,必須保證賦值結(jié)果的正確性,因此使用 assert 斷言。

五、總結(jié)

這篇文章分析了 C 語言中比較晦澀、模糊的一個(gè)概念,似乎有點(diǎn)虛無縹緲,但是的確又需要我們停下來仔細(xì)考慮一下。

如果有些場景,實(shí)在拿捏不好,我就會(huì)問自己一個(gè)問題:

這種情況是否被允許出現(xiàn)?

不允許:就用 assert 斷言,在開發(fā)階段就盡量找出所有的錯(cuò)誤情況;

允許:就用 if-else,說明這是一個(gè)合理的邏輯,需要進(jìn)行下一步處理。

【原創(chuàng)聲明】

轉(zhuǎn)載:歡迎轉(zhuǎn)載,但未經(jīng)作者同意,必須保留此段聲明,必須在文章中給出原文連接。
不吹噓,不炒作,不浮夸,認(rèn)真寫好每一篇文章!
歡迎轉(zhuǎn)發(fā)、分享給身邊的技術(shù)朋友,道哥在此表示衷心的感謝!轉(zhuǎn)發(fā)的推薦語已經(jīng)幫您想好了:

道哥總結(jié)的這篇總結(jié)文章,寫得很用心,對(duì)我的技術(shù)提升很有幫助。好東西,要分享!


推薦閱讀  

C語言指針-從底層原理到花式技巧,用圖文和代碼幫你講解透徹
一步步分析-如何用C實(shí)現(xiàn)面向?qū)ο缶幊?br/>我最喜歡的進(jìn)程之間通信方式-消息總線
物聯(lián)網(wǎng)網(wǎng)關(guān)開發(fā):基于MQTT消息總線的設(shè)計(jì)過程(上)提高代碼逼格的利器:宏定義-從入門到放棄
原來gdb的底層調(diào)試原理這么簡單
利用C語言中的setjmp和longjmp,來實(shí)現(xiàn)異常捕獲和協(xié)程
關(guān)于加密、證書的那些事
深入LUA腳本語言,讓你徹底明白調(diào)試原理

聲明: 本文由入駐維科號(hào)的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場。如有侵權(quán)或其他問題,請(qǐng)聯(lián)系舉報(bào)。

發(fā)表評(píng)論

0條評(píng)論,0人參與

請(qǐng)輸入評(píng)論內(nèi)容...

請(qǐng)輸入評(píng)論/評(píng)論長度6~500個(gè)字

您提交的評(píng)論過于頻繁,請(qǐng)輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無評(píng)論

暫無評(píng)論

人工智能 獵頭職位 更多
掃碼關(guān)注公眾號(hào)
OFweek人工智能網(wǎng)
獲取更多精彩內(nèi)容
文章糾錯(cuò)
x
*文字標(biāo)題:
*糾錯(cuò)內(nèi)容:
聯(lián)系郵箱:
*驗(yàn) 證 碼:

粵公網(wǎng)安備 44030502002758號(hào)