2008-11-06
案例 1
【案例描述】
下面通过测试中的一个例子来说明这个问题：命令DSP N7C是用来显示NO7电路状态的，其参数设备类型DID支持TUP和ISUP，参数信道号BSN支持多值输入（最多支持32路查询），正常情况下该命令没有问题。但试了非正常情况下，问题就出来了。
1、首先试BSN参数越界情况，即参数BSN超过32路查询，选了几个数据段，问题就出来了。对于0&&300和0&&256，该命令返回结果不一致，对前者认为参数越界，对后者返回执行成功。
2、对于参数DID，选定一种设备类型（TUP或ISUP），让参数BSN所包含的32路电路跨越TUP和ISUP，两次结果是不一致的。
【处理过程】
反馈到开发人员那里，第一个问题是BAM的问题，第二个问题是SM的问题。
【结 论】
1、为数据超出范围溢出造成，int值赋值给BYTE，造成数据丢失。
2、问题的产生是因为查询的第一个信道是TUP电路，但是却按ISUP电路查询。ISUP的维护处理函数判断第一个信道不是ISUP信道，认为整个的PCM不是ISUP类型的PCM，返回全部的电路状态为未安装。消息处理不合理。TUP也会产生如此错误。
【思考与启示】
我们的MML命令并不是无懈可击的，许多表面上的小问题，往往隐藏着代码的缺陷和错误。
评论1
楼主 2008/11/6 12:54:44
当我们使用PC-LINT检查代码时，会发现大量的数据类型不匹配的告警，大部分情况下，这种代码上存在的问题并不会引起程序功能实现上的错误，但有些情况下，也许会产生严重的问题：
一、不同数据类型变量之间赋值引起的问题，实际上，该类问题也可以分为几种情况：
1、直接赋值，比如，把一个WORD型变量赋给一个INT型变量，如果WORD型变量大于32767，INT型变量得到的就是一个负值了。
【例一】一次测试过程中发现，SDH送的告警在BAM调试窗口打印出红色提示：File(XXX),Line(XXX):Invalid alarm id ,from: 7, AlarmId: 65463
经过检查数据发现，并没有ID为65463的告警，分析上报的数据帧，发现上报的告警ID为B7，原来代码中有一处强制类型转换：
sdhAlmStru.AlarmId = (WORD)RecvBuffer[iTmpLen + 5];
char型强制转换成WORD型。B7就变成了FFB7，十进制就是65463。由于char是有符号型，B7的第8位为1，所以转换后为FFB7，而不是代码作者希望的00B7，如果第8位是0，或该变量是BYTE型，转换就不会有问题了。
2、函数形参和实参不一致，实际上和第一种情况本质上是一样的，只是表现的形式不太一样，这种情况也是代码中经常出现的问题,下面例子是测试中曾经发现的一个小问题：
【例二】在file01中的INT DebugMsgProc(char byMsg0, char byMsg1)函数，两个形参都是char型，而实际传入的参数都是BYTE型，结果函数中的如下语句：
PrintfE(PID_RED," %d ticks time out!",byMsg1);
在byMsg1大于127时，输出错误的结果。
