0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看威廉希尔官方网站 视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

嵌入式代码安全检查:选择if还是assert?

strongerHuang 来源:IOT物联网小镇 2024-04-13 11:45 次阅读

你们平时写代码时,有注意过代码的安全问题吗?那你们有做什么操作吗?今天就给大家分享一下相关的内容。

一、前言

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

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 
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,说明这是一个合理的逻辑,需要进行下一步处理。


声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 嵌入式
    +关注

    关注

    5082

    文章

    19118

    浏览量

    305008
  • 函数
    +关注

    关注

    3

    文章

    4329

    浏览量

    62590
  • 代码
    +关注

    关注

    30

    文章

    4786

    浏览量

    68565

原文标题:嵌入式代码安全检查:选择if还是assert?

文章出处:【微信号:strongerHuang,微信公众号:strongerHuang】欢迎添加关注!文章转载请注明出处。

收藏 人收藏

    评论

    相关推荐

    嵌入式系统“多大程度的 安全才算安全

    当今的嵌入式系统常常处理应用代码(IP)和数据等敏感信息,因此安全是其设计的一个主要关注因素。
    发表于 09-16 11:32 1457次阅读
    <b class='flag-5'>嵌入式</b>系统“多大程度的 <b class='flag-5'>安全</b>才算<b class='flag-5'>安全</b>”

    测量嵌入式软件的代码覆盖率

    角度还是从功能安全角度。 对于安全可靠的嵌入式设备,测试是质量保证不可或缺的一部分。 安全关键型软件开发标准对测试方法和测试覆盖率设定了精确
    发表于 07-14 14:50 1310次阅读
    测量<b class='flag-5'>嵌入式</b>软件的<b class='flag-5'>代码</b>覆盖率

    如何在if和assert中做选择

    的功能。以前我也是这么想的,但是,现在我不这么认为。 二、assert 断言刚才,我问了下旁边的一位工作 5 年多的嵌入式开发者:if 和 assert 如何选择?他说:
    发表于 04-08 06:13

    嵌入式学习到底选择自学还是培训?

    嵌入式自学和参加培训只是成本问题(时间成本,机会成本、金钱成本),如果你认为自学成本更低,当然可以选择自学,但往往很多人自学的路并不顺畅。于是乎买了了很多数 据结构、C++、操作系统、数 据库的书
    发表于 06-13 12:02

    嵌入式系统编程的语言选择代码优化

    ,加上运行环境复杂,使得嵌入式系统软件的开发变得异常困难。 为了设计一个满足功能、性能和时间要求的安全可靠的高性能嵌入式系统,编程语言的选择十分重要。
    发表于 07-22 08:18

    工作职业是选择嵌入式还是FPGA?

    也看不上)。如果选择了FPGA,就只能在有限的几个公司混了。而且FPGA相对于嵌入式linux更需要懂硬件,甚至有时候要亲自动手搞点硬件。但是好处就是门槛高,可替代性差。至于嵌入式linux,岗位多
    发表于 09-22 14:38

    Caché嵌入式代码分享

    文章目录第十章 Caché 嵌入式代码嵌入式HTML`&html`标记语法嵌入式JavaScript嵌入式SQL第十章 Caché
    发表于 12-17 07:19

    怎么样选择嵌入式Linux开发工具

    怎么样选择嵌入式Linux开发工具 嵌入式Linux具有稳定、可伸缩及开放源代码等特点,可兼容多种处理器和主机,广泛适用于各种产品和应用。但是,交叉
    发表于 09-10 10:17 1112次阅读
    怎么样<b class='flag-5'>选择</b><b class='flag-5'>嵌入式</b>Linux开发工具

    嵌入式安全及连接安全

    嵌入式安全及连接安全
    发表于 12-30 17:43 19次下载

    如何构建基于处理器的嵌入式安全系统 

    嵌入式安全系统概述;嵌入式系统安全威廉希尔官方网站 ;安全应用处理器介绍 ;基于安全处理器的
    的头像 发表于 01-25 07:06 2560次阅读
    如何构建基于处理器的<b class='flag-5'>嵌入式</b><b class='flag-5'>安全</b>系统 

    关于嵌入式代码的致命漏洞

    随着互联网的发展,嵌入式设备正分布在一个充满可以被攻击者利用的源代码安全漏洞的环境中。因此,嵌入式软件开发人员应该了解不同类型的安全漏洞—
    的头像 发表于 01-06 15:13 1798次阅读

    嵌入式代码的致命安全漏洞

    随着互联网的发展,嵌入式设备正分布在一个充满可以被攻击者利用的源代码安全漏洞的环境中。因此,嵌入式软件开发人员应该了解不同类型的安全漏洞—
    的头像 发表于 01-15 15:07 2204次阅读

    嵌入式外中断c语言代码

    嵌入式外中断c语言代码(arm嵌入式开发实例)-嵌入式外中断c语言代码,有需要的可以参考!
    发表于 07-30 11:29 4次下载
    <b class='flag-5'>嵌入式</b>外中断c语言<b class='flag-5'>代码</b>

    嵌入式开发蜂鸣器代码

    嵌入式开发蜂鸣器代码
    发表于 03-29 17:04 3次下载

    嵌入式系统的外设器件选择

    ,都可视系统的实际需求来进行选择。本文将为您介绍上述外设器件的类型与选择的考虑要素。 存储器的种类众多且特性不同 存储器 在嵌入式系统中,[存储器]是一个关键的器件,它用于存储程序代码
    的头像 发表于 05-05 09:38 903次阅读
    <b class='flag-5'>嵌入式</b>系统的外设器件<b class='flag-5'>选择</b>