【文章內容簡介】 也就是說在數據恢復或保存時把原數據的第一個 1給忽略了。此時第一個想法是：在程序處理中，把無符號長整型變量當作短整型變量處理了，為了證實這個判斷，針對 17bit/4bytes類型又重新設計測試用例：（ 1） 先建 PVC， DLCI=65535，然后保存，重起 MUX，觀察 PVC的恢復情況，發(fā)現 PVC能夠正確恢復； （ 2）再建 PVC， DLCI=65536，然后保存，重起 MUX，觀察 PVC的恢復情況，此時 PVC不能正確恢復。 至此基本可以斷定原因就是出在這里。帶著這個目的查看原代碼，發(fā)現在以下代碼中有問題： int _GetFrDlci( DWORD* dwDlci, char* str, DWORD dwDlciType, DWORD dwPortType, DWORD dwSlotID, DWORD dwPortID) { DWORD tempDlci。 char szArg[80]。 char szLine[80]。 ID LowPVCEP。 DWORD dwDlciVal[5][2] = { {16,1007}, {16,1007}, {1024,64511}, {2048,129023}, {131072,4194303} } 。 ．．． } typedef struct tagFrPppIntIWF { ．．． WORD wHdlcPort。 WORD wHdlcDlci。 WORD wPeerHdlcDlci。 WORD wPeerOldAtmPort。 ．．． } SFrPppIntIWFData。 DWORD SaveFrNetIntIWFData ( DWORD *pdwWritePoint ) { BYTE bSlotID, bPeerSlotID。 DWORD dwCCID, dwPeerCCID。 WORD wHdlcPort, wAtmPort, wIci, wPeerIci, wPeerHdlcPort 。 WORD wCount。 ．．． } DWORD SaveFrNetExtIWFData ( DWORD *pdwWritePoint ) { BYTE bSlotID。 DWORD dwCCID, dwPeerCCID。 WORD wHdlcPort, wAtmPort, wIci 。 WORD wCount。 ．．． [wCount].bSlotID = bSlotID。 [wCount].wHdlcPort = wHdlcPort。 [wCount].wHdlcDlci = gFrPVCEP[bSlotID ][ gFrPVCC[bSlotID][dwCCID].dwLoPVCEP ].dwDLCI。 [wCount].wOldAtmPort = wAtmPort。 [wCount].wAtmDlci = gFrPVCEP[ bSlotID ][ gFrPVCC[bSlotID][dwCCID].dwHiPVCEP ].dwDLCI。 [wCount].dwMapMode = gFrPVCC[bSlotID][dwCCID].dwMapMode。 ．．． } DWORD RestoreFrNetExtIWFData ( WORD wSlotID, BYTE *pReadPoint ) { WORD wCount, wTotalNetIWF。 BYTE bSlotID, bHdlcDlciType, bAtmDlciType。 WORD wOldAtmPort, wAtmDlci, wHdlcPort, wHdlcDlci。 DWORD dwMapMode, dwCIR, dwBe。 DWORD dwCCID, dwResult, dwAtmPort。 wTotalNetIWF = 。 ．．． } DWORD RestoreFrHdlcIntIWFData ( WORD wSlotID, BYTE *pReadPoint ) { WORD wCount, wTotalHdlcIWF。 DWORD dwCCID, dwPeerCCID, dwAtmPort, dwPeerAtmPort。 DWORD dwResult。 BYTE bSlotID, bPeerSlotID。 WORD wHdlcPort, wOldAtmPort, wCIR。 WORD wPeerHdlcPort, wPeerOldAtmPort。 ．．． } 其中涉及 DLCI值的變量都為 WORD（即無符號短整型）類型，在程序的處理時，出現 WORD和 DWORD（無符號長整型）類型在一句中同時存在的情 況，至此可以判斷問題出在這里。由于 DLCI值在不同類型時的取值范圍不同，前三種類型的取值范圍為 16~991，第四種取值范圍為 2048~126975，第五種取值范圍為 131072~4194303，所以當采用前三種 DLCI類型時，采用 WORD類型最大值為 65535，已經完全夠用了；而對于第四種類型時，其取值在超過 65535時，獲取 DLCI值的函數 _GetFrDlci（）采用 DWORD類型，而負責保存和恢復的兩個函數 SaveFrNetExtIWFData（）和 RestoreFrNetExtIWFData（），都把 DLCI的值當作 WORD類型進行處理，因此導致 DLCI取值越界，于是程序把原本為長整型的DLCI強制轉換成整型，從而導致 DLCI值在恢復時，比原數據小 65536。而在程序運行過程中，這些數據保存在 DRAM中，程序運行直接從 DRAM中獲取數據，程序不會出錯；當 FRI板復位或插拔后，需要從 FLASH中讀取數據，此時恢復函數的錯誤就表現出來。 另一個問題是為什么 23/4類型的 DLCI數據不能恢復？這是由于對于 23/4類型的 PVC，其 DLCI的取值范圍為： 131072~4194303，而程序強制轉換并恢復的數據最大只能是 65535，所以這條 PVC不能恢復。 至此， DLCI數據恢復出錯的原因完全找到，解決的方 法是將 DLCI的類型改為 DWORD類型。從這個案例可以看出，在程序開發(fā)中一個很低級的錯誤，將在實際工作中造成很嚴重的后果。 正確使用邏輯與 amp。amp。、屏蔽 amp。操作符 【案例 】 【案例描述】：由于 C語言中位與比求模效率高，因而系統(tǒng)設計時，對于模 128的地方都改為與 127，系統(tǒng)定義的宏為 define MOD128 127和 define W_MOD 127(定義的宏的名字易引起誤解 )，但實際程序中還是采取求模，從而引起發(fā)送窗口欲重發(fā)的和實際重發(fā)的不一致，最終導致鏈路復位此類嚴重問題，曾在定位此 問題時花了不少時間。 【處理過程】：處理過程如下： define MOD128 127 //隊列長 128，當隊頭到 128時，上其返回。 define W_MOD 127 //發(fā)送窗口隊列，意義同上。 在函數 L2_TO_L1()中，有如下語句： linkstate_ptr = (head + 1) % W_MOD 。 這里當 head=126時， = 0，這將造成發(fā)送窗口指針和隊列窗口 指針錯位，造成鏈路復位 。 另外，在重發(fā)函數 void INVOKE_RETRANSMISSION(_US logic_link,_US n_r)中，有如下語句： retran_num = (LinkState[logic_link].Vs + MOD128 (_UC)n_r) % MOD128 。 w_head = (LinkState[logic_link]. + W_MOD retran_num) % W_MOD 。 第一個語句求欲重發(fā) 的消息包個數，第二個語句求重發(fā)的起始位置，當 Vs小于n_r時，將造成實際重發(fā)數小于欲重發(fā)數，同時造成實際起始重發(fā)位置和欲重發(fā)起始位置錯開，從而引起鏈路復位。上面三個語句應該做如下改動： linkstate_ptr = (head + 1) amp。 W_MOD 。 retran_num = (LinkState[logic_link].Vs + MOD128 + 1 (_UC)n_r) amp。 MOD128 。 w_head = (LinkState[logic_link]. + W_MOD + 1 retran_num) amp。 W_MOD 。 【結 論】：由于鏈路通信對系統(tǒng)效率要求很高，算法采用效率最高的，但位與（ amp。）和求模（ %）這小小的區(qū)別，造成的竟是鏈路復位這種嚴重的錯誤。 【思考與啟示】：對這類問題，大家在閱讀代碼或代碼審查時一定要注意，仔細一點往往能發(fā)現問題，但在測試中來定位這種問題，花費的時間往往更長。 注意數據類型的匹配 【案例 】 【案例描述】 下面通過測試中的一個例子來說 明這個問題：命令 DSP N7C是用來顯示 NO7 電路狀態(tài)的，其參數設備類型 DID支持 TUP和 ISUP，參數信道號 BSN支持多值輸入（最多支持 32路查詢），正常情況下該命令沒有問題。但試了非正常情況下，問題就出來了。 首先試 BSN參數越界情況，即參數 BSN超過 32路查詢，選了幾個數據段，問題就出來了。對于 0amp。amp。300和 0amp。amp。256，該命令返回結果不一致，對前者認為參數越界，對后者返回執(zhí)行成功。 對于參數 DID，選定一種設備類型（ TUP或 ISUP），讓參數 BSN所包含的32路電路跨越 TUP和 ISUP， 兩次結果是不一致的。 【處理過程】 反饋到開發(fā)人員那里，第一個問題是 BAM的問題，第二個問題是 SM的問題。 【結 論】 為數據超出范圍溢出造成， int值賦值給 BYTE，造成數據丟失。 問題的產生是因為查詢的第一個信道是 TUP電路，但是卻按 ISUP電路查詢。 ISUP的維護處理函數判斷第一個信道不是 ISUP信道，認為整個的 PCM不是ISUP類型的 PCM，返回全部的電路狀態(tài)為未安裝。消息處理不合理。 TUP也會產生如此錯誤。 【思考與啟示】 我們的 MML命令并不是無懈可擊的，許多表面上的小問題， 往往隱藏著代碼的缺陷和錯誤。 【案例 】 【正 文】 當我們使用 PCLINT檢查代碼時，會發(fā)現大量的數據類型不匹配的告警，大部分情況下，這種代碼上存在的問題并不會引起程序功能實現上的錯誤，但有些情況下，也許會產生嚴重的問題： 一、不同數據類型變量之間賦值引起的問題，實際上，該類問題也可以分為幾種情況： 直接賦值，比如，把一個 WORD型變量賦給一個 INT型變量，如果WORD型變量大于 32767， INT型變量得到的就是一個負值了。 【例一】一次測試過程中發(fā) 現， SDH送的告警在 BAM調試窗口打印出紅色提示： File(XXX),Line(XXX):Invalid alarm id ,from: 7, AlarmId: 65463 經過檢查數據發(fā)現，并沒有 ID為 65463的告警，分析上報的數據幀，發(fā)現上報的告警 ID為 B7，原來代碼中有一處強制類型轉換： = (WORD)RecvBuffer[iTmpLen + 5]。 char型強制轉換成 WORD型。 B7就變成了 FFB7，十進制就是 65463。由于 char是有符號型， B7的第 8位為 1，所以轉換后為 FFB7，而不是代碼作者希望的 00B7，如果第 8位是