博客
关于我
留意编译告警
阅读量:552 次
发布时间:2019-03-09

本文共 829 字,大约阅读时间需要 2 分钟。

在我参与过的一个项目中,我们增加了PcLint检查,但由于规则设置的缘故,有一个bug没有产生PcLint告警。在最终定位问题后,我们才发现它实际上已经导致了一个编译告警但被忽视,因为项目组没有要求代码必须清除所有告警。这个bug非常低级,是一个赋值时的精度丢失。具体代码如下:

nAvailPageFile = ullAvailPageFile;

前者是32位的int类型,后者是64位的DWORDLONG类型。编译器已经做出了提示,但却被忽视了:

warning C4244: “=”: 从“DWORDLONG”转换到“int”,可能丢失数据

也许你的工程中编译告警太多,由于破窗效应已经无暇顾及。但里面可能隐藏着bug,需要逐一排查把告警消除。这样当代码产生新的告警时才容易被发现。

当然,处理告警时同样得小心仔细。考虑下面这段代码:

DWORD dwBytes;char tmpBuf[BUF_SIZE];...

由于局部变量dwBytes没有被使用产生了一个告警:

warning C4101: “dwBytes”: 未引用的局部变量

如何消除这个告警呢?你的第一反应可能是把第一行dwBytes的定义注释掉。当然这是正确的做法。但也许注释掉以后再进行测试时,程序有可能会崩溃!原因如下:

有时候代码bug是“潜伏”的,往往两个bug在一起会相互抵消,不会暴露。当修改了其中一个bug后,另一个bug就暴露出来,导致程序异常。这里的另一个潜在问题是,代码中第二个局部变量tmpBuf在使用过程中可能存在内存越界,且越界的长度不多,刚好在4个字节范围内。当内存越界时,实际上使用了dwBytes变量所处的内存,而刚好dwBytes又没有被使用。因此程序运行平安无事。当dwBytes被注释掉以后,内存越界就踩到了函数的堆栈,堆栈被破坏后函数返回时,程序就崩溃了。因此每修改一行代码都需要充分评估修改前后的差异。留意编译告警,不要放过每一个潜在的问题。

转载地址:http://dkriz.baihongyu.com/

你可能感兴趣的文章
NIFI汉化_替换logo_二次开发_Idea编译NIFI最新源码_详细过程记录_全解析_Maven编译NIFI避坑指南001---大数据之Nifi工作笔记0068
查看>>
NIFI集群_内存溢出_CPU占用100%修复_GC overhead limit exceeded_NIFI: out of memory error ---大数据之Nifi工作笔记0017
查看>>
NIH发布包含10600张CT图像数据库 为AI算法测试铺路
查看>>
Nim游戏
查看>>
NIO ByteBuffer实现原理
查看>>
Nio ByteBuffer组件读写指针切换原理与常用方法
查看>>
NIO Selector实现原理
查看>>
nio 中channel和buffer的基本使用
查看>>
NIO基于UDP协议的网络编程
查看>>
NISP一级,NISP二级报考说明,零基础入门到精通,收藏这篇就够了
查看>>
Nitrux 3.8 发布!性能全面提升,带来非凡体验
查看>>
NI笔试——大数加法
查看>>
NLog 自定义字段 写入 oracle
查看>>
NLog类库使用探索——详解配置
查看>>
NLP 基于kashgari和BERT实现中文命名实体识别(NER)
查看>>
NLP 项目:维基百科文章爬虫和分类【01】 - 语料库阅读器
查看>>
NLP_什么是统计语言模型_条件概率的链式法则_n元统计语言模型_马尔科夫链_数据稀疏(出现了词库中没有的词)_统计语言模型的平滑策略---人工智能工作笔记0035
查看>>
NLP学习笔记:使用 Python 进行NLTK
查看>>
NLP的神经网络训练的新模式
查看>>
NLP问答系统:使用 Deepset SQUAD 和 SQuAD v2 度量评估
查看>>