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

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

Java编程不涉及本节内容,因为它在编译时语法检查更加严格,要么出错要么成功。C/C++也许是太过于灵活,或者由于历史原因,编译时除了产生错误还会产生告警。同时程序中编译告警容易被忽视,但其中往往隐含着一些潜在的问题。

我曾经参与过的一个项目中增加了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/

你可能感兴趣的文章
mysql 断电数据损坏,无法启动
查看>>
MySQL 日期时间类型的选择
查看>>
Mysql 时间操作(当天,昨天,7天,30天,半年,全年,季度)
查看>>
MySQL 是如何加锁的?
查看>>
MySQL 是怎样运行的 - InnoDB数据页结构
查看>>
mysql 更新子表_mysql 在update中实现子查询的方式
查看>>
MySQL 有什么优点?
查看>>
mysql 权限整理记录
查看>>
mysql 权限登录问题:ERROR 1045 (28000): Access denied for user ‘root‘@‘localhost‘ (using password: YES)
查看>>
MYSQL 查看最大连接数和修改最大连接数
查看>>
MySQL 查看有哪些表
查看>>
mysql 查看锁_阿里/美团/字节面试官必问的Mysql锁机制,你真的明白吗
查看>>
MySql 查询以逗号分隔的字符串的方法(正则)
查看>>
MySQL 查询优化:提速查询效率的13大秘籍(避免使用SELECT 、分页查询的优化、合理使用连接、子查询的优化)(上)
查看>>
mysql 查询数据库所有表的字段信息
查看>>
【Java基础】什么是面向对象?
查看>>
mysql 查询,正数降序排序,负数升序排序
查看>>
MySQL 树形结构 根据指定节点 获取其下属的所有子节点(包含路径上的枝干节点和叶子节点)...
查看>>
mysql 死锁 Deadlock found when trying to get lock; try restarting transaction
查看>>
mysql 死锁(先delete 后insert)日志分析
查看>>