评论4

• 

  xilinxue

  楼主 2008/11/7 13:17:28

   一般开发人员认为函数的参数很简单，但在实际设计和调用函数时，很容易犯一些参数方面的错误。下面就一些例子进行一些分析，希望能引起大家的重视。
   1、函数设计中，使用函数内局部变量保存下次函数重新调用时需要的保留值。
  void SlaverDownLoadProc( WORD wMsgLength , void *pTempMsgAddr )
  {
   void *pTempTargetAddr ;

  
  

   SSLAVERLOADMSG *pSTempSlaverLoadMsg = ( SSLAVERLOADMSG * )pTempMsgAddr; 
   
   if ( COMMON_BOARD_LOAD_PROGRAM == pSTempSlaverLoadMsg->m_ucCmd )
    pTempTargetAddr = ( void * )SDRAM_LOAD_PROG_START_ADDR ;
  #ifndef MMX  /* MMX板的数据不用加载，用备份方式*/
   else if ( COMMON_BOARD_LOAD_FPGA == pSTempSlaverLoadMsg->m_ucCmd )
    pTempTargetAddr = ( void * )SDRAM_FPGA_START_ADDR ;
                ...
             
              case BEGIN_LOAD :
          if (  ( LOAD_MIDDLE_FRAME == pSTempSlaverLoadMsg->m_ucLoadCmd )
       &&( ( dwRecFrameNum % 0xFF ) == pSTempSlaverLoadMsg->m_ucOrderNo )  
      )
   {
   /* 序号和帧的命令字都是合法的，保存BUFFER */
    memcpy( ( BYTE * )pTempTargetAddr , ( BYTE * )pSTempSlaverLoadMsg + 5 , wMsgLength - 5 ) ;
   /* 5 = m_ucBoardType + m_ucCmd + m_ucSerialNo + m_ucLoadCmd + m_ucOrderNo */
    dwRecFrameNum ++ ;
                  ...
         
   这里每收到一帧都要调用此函数，而每次进入时，函数将pTempTargetAddr赋值为两个固定值中的一个，导致收到的新帧将上一次的帧数据覆盖。显然，函数将本应作为全局变量的参数pTempTargetAddr错误地定义为局部变量。
   2、当函数的输入参数较多，并且互相之间有联系时，是较易出错的地方。
   在测试串口任务时，我们发现一个错误：当加入新用户时，当用户名输入到四十一个字符时，程序死掉。经过调试跟踪，发现是在input函数中调用GetString，但是在对第二个参数赋值时，没有搞清楚参数之间的关系。第一个参数（传入的指针）指向一长度为40字符的字符串，而在对第二个参数时，错误地将字符串长度设置为41。导致串口接收第41个字符时，程序越界操作，导致死机。下面是函数GetString的声明：
  signed long GetString
  (
      char * szString,         /* OUT: 字符串指针 */
      WORD wSize            /* IN: 指定的字符串长度 */
  )
  1
   当然有关函数参数的错误不止这些，例如未在模块接口函数内部检验传入参数的合法性、指针参数的有效性、参数未赋值就使用、参数类型不匹配或考虑不周导致上溢下溢等。这些都是编程者容易出错的地方，亦是我们大家在走读代码时，需要特别注意的地方。

• 

  xilinxue

  楼主 2008/11/7 13:17:44

   在交换机的V5协议测试中，有一个相当常用又相当简单的测试项目，“交换机对某个V5接口发起主备倒换命令”。这在所有的V5测试中都会很顺利地通过的项目，在以前这个项目也测试过许多次，也从来没有遇到过异常情况。
   可是在一次测试中却遇到麻烦，在交换机侧输入了参数“模块号”、“V5接口号”、“逻辑C通道ID”之后，发起主备链路倒换的命令，操作的结果居然是“无效的V5端口”。
   这种提示令人感到很诧异，因为从AN侧能够正常发起主备链路倒换，从LE侧也能正常发起该V5端口的指定链路倒换，而且系统也完全正常，可见数据配置并没有错误。排除了人为的错误之后，我把重点放到了这三个输入参数上：“模块号”，“V5接口号”均是非常常规的数值，应该没有问题；“逻辑C通道ID”数值比较大，但是仍然在协议规定的65535之内，应该为有效值。想到常规配置数据时“逻辑C通道ID”值一直配得比较小，或许问题就出在此。
   于是把“逻辑C通道ID”值改小，再作同样的操作，操作成功。到此很显然是这个参数的有效值范围定义有误，再细细检查，发现它只在单字节范围内有效，必然是该参数定义的类型有误。原因是：在函数OAM_Swap_Communication_Link（_UC v5_interface，_UC logic_c_id）里将逻辑C通道定义为字符型导致，改为_US型即解决。
   推而广之，在终端的功能测试中，对输入参数值的测试，应该尽量覆盖所有的有效值。在正常情况下，如果输入值在为有效值，则应该得出正确的结果；如果输入值为非法值，则系统应该给出错误提示，并且不予执行。 对于参数值有效性的判断，特别应该注意一些特殊值和临界值，比如在字节和双字节处等等。

• 

  xilinxue

  楼主 2008/11/7 13:18:04

  现象与分析：
          在回归“载频配置表及跳频数据表中有零频点或重复频点时，MA编码不正确”问题单时。发现当载频配置表及跳频数据表中有重复频点或零频点时，带跳频的呼叫不成功。
           这时首先考虑系统消息发的是否正确，观察系统消息一，发现所带的CA表没有错误，已经过滤掉了重复频点和零频点。
           在考虑指配命令所带的MA值是否正确，结果发现MA编码也是正确的，也已经过滤掉重复频点和零频点。   
           经过以上初步分析以后，开始怀疑给基站下配置时是否也正确过滤了无效频点。然后查阅代码，发现果然 BTSM在对基站初始化设置载频属性及设置信道属性时，没有对载频配置表及跳频数据表中频点的有效性做检查，以致于表中出现非法频点时跳频呼叫不成功。
   
    回顾与反思：
            这个问题的发现并没有用什么特殊的分析方法，只不过是一般的“排除法”，而且这个问题也不是隐藏的非常之深，但是我觉得这个问题的发现暴露了我们在开发过程中的一个问题。那就是：如何实现各个模块之间的有效沟通，避免因为某一模块的修改而引起其他模块的连锁反映。
          本来RR和BTSM都没有考虑重复频点和零频点的情况，大家都寄托与数据配置的正确，却也相安无事。RR首先增加了对非法频点的过滤，本来是件好事，使我们的系统变的更加坚强，但是BTSM并不知道这一变化，于是在错误数据面前束手无策，反而起到了相反的效果。
          公司常说“下一道工序是上一道工序的上帝”，是不是可以引申为“其他相关模块是本模块的上帝”。试想如果各个模块多想想自己的改动是否给别人带来不良影响，多及时了解一下其他模块的最新进展。那么此类问题将不再会发生。

• 

  xilinxue

  楼主 2008/11/7 13:18:26

  现象与分析：
           在动态数据配置测试增加小区时，发现小区不能正常初始化。观察ABIS_BTSM接口跟踪窗口，没有关于初始化流程的相关消息。经过分析发现是调用函数。
     BTSM_make_send_site_config(_UC site_no , _UC ObjectClass , _US BTS_no ,_UC TRX_no , _UC OperMode)
  {
       ………
      //判断合法性
      if ((site_no >= MAX_SITE_NUM)
          || (BTS_no >= MAX_BTS_NUM)
          || (TRX_no >= MAX_TRX_A_BTS))
      {
           ASSERT(FALSE);
           return (FALSE);
      }
  　　………
  }
  由于进行小区级的操作调用该函数时，TRX_NO以0xFF带入，则在函数合法性检查时就会返回。从而引发该错误。

  
  

  回顾与反思：
      这是一个比较普通的错误，但是回顾它产生和解决的过程，觉得很有启发，也引起了我对编程规范的一些思考。

  
  

   可以说该错误的引起是与编程规范有关,本来函数 BTSM_make_send_site_config()没有对 BTS_no和TRX_no 的合法性判断，在代码审查时，我们考虑到这不符合编程规范中的“检查所有参数输入的有效性”这一条，于是提出请开发人员增加对参数的有效性检查。
           但是我们和开发人员都忽略的一个问题，那就是，该函数被不同级别的对象调用，当进行小区级操作时，TRX_NO以0xFF带入，则在函数合法性检查时就会返回，引起上述错误。
      让我们再回头看看这个函数，发现依然不符合编程规范，至少违反了“不要设计多用途面面俱到的函数”这一条。
      查看我们的代码，类似的问题还有不少，而且诸如：函数入口参数不加有效性检查、函数返回值不加处理等问题也可以找到。这些问题就象一颗颗隐型炸弹，在稍微不注意时就会带来严重后果。
      正如前文所述，测试和开发人员都会因为“代码熟悉程度”、“代码编制时间太久有所遗忘”等诸如此类的原因而忽略一些问题。这时，良好的程序风格和编程规范就会成为一把强有力的保护伞。试想如果本文所提到的函数从设计到开发都严格按照规范来进行，那么这个问题就没有产生的土壤，如果我们的每一段代码的编写都严格遵守规范，那么我们的系统将变的有多么坚不可摧。