代码安全性和健壮性：如何在if和assert中做选择?

怼烎@ 2022-11-04 14:21 135阅读 0赞

**关注+****星标公众****号**，不错过精彩内容

![873cf7c27208d1812212dd0d872cbfc9.gif][]

作者 | 道哥

转自 | IOT物联网小镇

嵌入式软件开发，实际项目通常会考虑代码的一些安全性和健壮性，一般来说，需要添加一些“检测”的代码。

下面就来为大家分享一下关于if和assert的内容。

## 一、前言 ##

我们在撸代码的时候，经常需要对代码的安全性进行检查，例如：

> 1. 指针是否为空？  
> 2. 被除数是否为 0？  
> 3. 函数调用的返回结果是否有效？
> 
> 4. 打开一个文件是否成功？

对这一类的边界条件进行检查的手段，一般都是使用 if 或者 assert 断言，无论使用哪一个，都可以达到检查的目的。那么是否就意味着：这两者可以随便使用，想起来哪个就用哪个？

这篇小短文我们就来掰扯掰扯：在不同的场景下，到底是应该用 if，还是应该使用 assert 断言？

写这篇文章的时候，我想起了孔乙己老先生的那个问题：茴香豆的“茴”字有几种写法？

似乎我们没有必要来纠结应该怎么选择，因为都能够实现想要的功能。以前我也是这么想的，但是，现在我不这么认为。

成为技术大牛、拿到更好的offer，也许就在这些细微之间就分出了胜负。

## 二、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 这个宏。

## 三、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 断言。

## 五、总结 ##

这篇文章分析了 C 语言中比较晦涩、模糊的一个概念，似乎有点虚无缥缈，但是的确又需要我们停下来仔细考虑一下。

如果有些场景，实在拿捏不好，我就会问自己一个问题：

这种情况是否被允许出现？

不允许：就用 assert 断言，在开发阶段就尽量找出所有的错误情况；

允许：就用 if-else，说明这是一个合理的逻辑，需要进行下一步处理。

\------------ **END** ------------

**推荐阅读：**

[**精选汇总 | 专栏 | 目录 | 搜索**][_ _ _ _ _]

[**精选汇总 | 嵌入式C语言**][_ _C]

[**精选汇总 | STM32、单片机**][_ STM32]

**欢迎关注我的公众号，**回复“**加群**”按规则加入技术交流群，回复“**1024**”查看更多内容。

**欢迎关注我的视频号：**

![ca48bc58fdf8f33eae0e77954a6e6ce5.png][]

点击“**阅读原文**”查看更多分享，欢迎**点分享、收藏、点赞、在看。**

[873cf7c27208d1812212dd0d872cbfc9.gif]: /images/20221023/31a0b357d7c743e3955a4347fae7a01a.png
[-]: https://mp.weixin.qq.com/s?__biz=MzA3MzAwODYyNQ%3D%3D&idx=1&mid=2247484335&scene=21&sn=084405e8704d059700496df998f55b2a#wechat_redirect
[_ _ _ _ _]: http://mp.weixin.qq.com/s?__biz=MzI4MDI4MDE5Ng%3D%3D&chksm=ebb85ad7dccfd3c1e2145ac7fb9a584d9a726faa6420f37d4b79e3bda5efe2c59ae8b77fd358&idx=3&mid=2247497532&scene=21&sn=519e2d777352f9049f6a96546009273c#wechat_redirect
[_ _C]: https://mp.weixin.qq.com/s?__biz=MzI4MDI4MDE5Ng%3D%3D&idx=4&mid=2247496909&scene=21&sn=d70a1bc139e2dadb9e0461595394436c#wechat_redirect
[_ STM32]: https://mp.weixin.qq.com/s?__biz=MzI4MDI4MDE5Ng%3D%3D&idx=2&mid=2247497461&scene=21&sn=ce3c8b02bb0f2c787a743e0d0203eb0d#wechat_redirect
[ca48bc58fdf8f33eae0e77954a6e6ce5.png]: /images/20221023/b6b5c74a3c014fa4bd05fdeab1800bdd.png