數(shù)組越界真可怕，莫名就闖到了別人家

　　4

　　筆者曾經(jīng)在《天靈靈地靈靈，遙控為何會失靈》一文中講述過報文解析程序的一部分原理和設計，

　　“射頻位到數(shù)據(jù)位采用了曼徹斯特編碼形式，以射頻位01表示數(shù)字位1，以射頻位10表示數(shù)字位0，BCM采用上升沿觸發(fā)中斷的方式，根據(jù)相鄰兩個上升沿之間的時間間隔來賦值射頻位。BCM根據(jù)遙控報文的格式提取出“數(shù)據(jù)場”中的射頻位位流，然后進行曼徹斯特解碼，計算出數(shù)據(jù)位位流，進而提取出字節(jié)形式的數(shù)據(jù)。。。。相鄰兩個上升沿的間隔取值只可能為2T、3T、4T，T為射頻位位寬。”

　　前文所述“把數(shù)據(jù)位0或1這個‘大象’放到前面打開的‘冰箱’里”，指的就是賦值射頻位的過程，

　　如果是2T，執(zhí)行StoreRfBit(0); StoreRfBit(1);

　　如果是3T，執(zhí)行StoreRfBit(1); StoreRfBit(0); StoreRfBit(1); 或者StoreRfBit(0); StoreRfBit(1);

　　StoreRfBit(0);

　　如果是4T，執(zhí)行StoreRfBit(1); StoreRfBit(0); StoreRfBit(0); StoreRfBit(1);

　　遙控報文的格式非常規(guī)整，能夠很容易地找到數(shù)據(jù)場的第一位，然后次序收完數(shù)據(jù)場的最后一位，本不該出現(xiàn)接收報文失敗的問題。既然無法通過分析代碼找出bug，那就只好祭出“調(diào)試大法”了。繼續(xù)添加測試語句：

　　if(Rf_bit_count >= RF_RAWBIT_LEN){

　　Rf_frame_times++;

　　StoreRfCompleteIdx();

　　SetRfFrameComplete();

　　}

　　灑家這次沒有吝惜RAM，開了個足以存儲好幾條報文射頻位位寬數(shù)據(jù)的輪轉(zhuǎn)型大數(shù)組，在判斷接收到一幀完整的報文語句那里存儲完整報文最后一個數(shù)據(jù)位在輪轉(zhuǎn)型大數(shù)組中的下標位置，設置斷點，運行到斷點位置后，便可以從這個數(shù)組下標往前搜索，看看之前幾個報文的射頻位位寬數(shù)據(jù)是否有什么異常。

　　聰明的讀者肯定已經(jīng)搶先一步意識到了，射頻位位寬沒有出現(xiàn)任何異常。報文頭很規(guī)則，數(shù)據(jù)場很整齊，報文尾部也很利落。

　　總之，所有的射頻位數(shù)據(jù)安安靜靜地等待在時間的無涯荒野里，沒有早一步，也沒有晚一步，我遇上了，卻沒有輕輕地說一句：哦，原來你也在這里呵！

　　灑家揉了揉因為看數(shù)據(jù)看得有些發(fā)脹的眼睛，緩緩走到窗臺前，瞇縫起眼睛，打量了一下遠處籠罩在一片蜃氣之中的青山。每每遇到難解的問題，灑家總要到窗臺陽光的沐浴中，眺望一下遠處的山，讓腦袋放空，然后閉上眼睛，靜下心來，等著靈感不請自來。

　　中央空調(diào)沙沙的換氣聲音、同事的竊竊私語聲不時入耳，我在心里不斷回憶著有限的職業(yè)生涯里遇到的一個個bug，同時盤算著當前程序可能的缺陷。報文格式的分段解析肯定沒問題，射頻位位寬的判斷也沒問題，射頻位的賦值也沒問題，想來都沒有問題，這個bug隱藏地夠深的。

　　5

　　還得調(diào)試！行文至此，我不禁懷疑起了自己的智商，為什么基本上所有難題的解決都是靠調(diào)試解決的？沒有一次是靈光電閃，看代碼直搗黃龍，找出bug的？

　　被這個難題耗損了大半豪氣的我，老老實實地開始調(diào)試起來。為了定位bug，筆者特意修改了程序結(jié)構(gòu)，之前的程序是邊接收邊解析，實時性固然好，但是接收了幾個數(shù)據(jù)便解析，不利于調(diào)試，所以改為收到兩三條報文后，再集中進行解析。

　　灑家看代碼找bug的本事沒有，設計調(diào)試方案找bug的能力還是有的。修改程序之后，調(diào)試下來，問題就慢慢浮上水面了。程序解析出報文頭部，進入數(shù)據(jù)場之后，在賦值射頻位的過程中，結(jié)果出現(xiàn)了Rf_bit_count從288累加到33的情形！?。?/p>

　　奇怪了，288累加一下應該是289，怎么就變成33了？莫非1+1不等于2了不成？??！此處肯定有蹊蹺，灑家打眼一瞧，馬上看出了一點端倪，289和33正好差了一個256，就好像是把向高字節(jié)的進位吃掉了一般。問題開始變得有趣了！

　　Rf_bit_count是個16位的數(shù)據(jù)，好像突然變成了8位數(shù)據(jù)，顯然，它的高位字節(jié)發(fā)生了不為人知的變化！寫過多年代碼的灑家，立馬想到了是和Rf_bit_count臨近空間的數(shù)據(jù)搞的鬼，回到定義位置一看，

　　uint8_t  Rx_buffer[RF_DATA_LEN];

　　uint8_t  Rx_rawbit[RF_RAWDATA_LEN];

　　uint16_t Rf_bit_count;

　　一切都了然了，Rf_bit_count挨著Rx_rawbit這個數(shù)組，肯定是Rx_rawbit這個數(shù)組搞的事，這個數(shù)組越了界，就會改變Rf_bit_count的數(shù)據(jù)，下面就簡單了，看看是不是這回事！

　　我飛速地在紙上算了一下，當Rf_bit_count=288時，右移三位為36，Rf_rawbyte_idx =36時，Rx_rawbit數(shù)組正好越界，由于Rf_bit_count的位置正好在Rx_rawbit之后，而且所使用的處理器是大端模式，大端方式將高位存放在低地址，小端方式將低位存放在低地址。

所以，Rf_bit_count的高字節(jié)正好挨著Rx_rawbit數(shù)組，肯定是對Rx_rawbit[36]賦值為0了，導致Rf_bit_count本來是1的高字節(jié)變成了0，于是289就變成了33，這樣一來，判斷接收到一條完整報文的語句里的if語句里的條件肯定是false了，于是，好好的一幀數(shù)據(jù)就這樣被漏掉了。

　　if(Rf_bit_count >= RF_RAWBIT_LEN){

　　SetRfFrameComplete();

　　}

　　當然，細心的讀者可能會比較奇怪，只需要接收288個射頻位，為什么Rf_bit_count還會累加到289呢？

　　這是因為，最后一個數(shù)據(jù)位可能是1也可能是0，最后統(tǒng)計到的射頻位寬可能是2T、3T或者4T，它們執(zhí)行的Rf_bit_count是不一樣的，有時正好統(tǒng)計到288，那自然萬事大吉，可以接收到報文，可是有時就會超過288，如前所述，這時它的高字節(jié)就有可能會被Rx_rawbit[36]吃掉，這就接收不到報文了。

　　后記

　　筆者學過一段時間的Java，Java對數(shù)組進行了一定的安全處理，在運行期間會自動判斷數(shù)組下標是否越界，當時看的灑家羨慕得不得了。在計算機的世界里，C語言飽經(jīng)滄桑，年頭太老了，這種優(yōu)異的特性顯然指望不上，我等嵌入式工程師只能擦亮慧眼，始終保持警惕，要知道：數(shù)組越界真可怕，莫名就闖到了別人家。